summaryrefslogtreecommitdiffstats
path: root/zebra/zebra_rib.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* zebra: Add code to set SRv6 encap source addr in dplaneCarmine Scarpitta2023-12-141-0/+1
| | | | | | | | Add a bunch of set functions and associated data structure in zebra_dplane to allow the configuration of the source address for SRv6 encap in the data plane. Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
* zebra: The dplane_fpm_nl return path leaks memoryDonald Sharp2023-12-111-0/+6
| | | | | | | | The route entry created when using a ctx to pass route entry data backup to the master pthread in zebra is being leaked. Prevent this from happening. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* Merge pull request #14968 from opensourcerouting/fix/missing_whitespaceDonald Sharp2023-12-101-1/+1
|\ | | | | zebra: Add missing whitespace when printing route entry status
| * zebra: Add missing whitespace when printing route entry statusDonatas Abraitis2023-12-081-1/+1
| | | | | | | | | | | | | | | | | | | | Before: ``` status: Removed ReplacingInstalled ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
* | zebra: enqueue NHG_DEL in rib_nhg meta queuePhilippe Guibert2023-12-071-10/+52
|/ | | | | | | | | | | | | | | | | | The NHG_DEL operation is done directly from ZAPI call, whereas the NHG_ADD operation is done in the rib_nhg meta queue. This may be problematic when ADD is followed by DEL. Imagine a scenarion with two protocol NHIDs. <NH1> depends of <NH2> and <NH3>. The deletion of <NH3> at the protocol level will trigger 2 messages to ZEBRA: NHG_ADD(<NH1>) and NHG_DEL(<NH3>). Those operations are properly enqueued in ZAPI, but in the end, the NHG_DEL is executed first. This causes NHG_ADD to unlink an already freed NHG. Fix this by consistently enqueuing NHG_DEL and NHG_ADD operations. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* Merge pull request #14795 from donaldsharp/zebra_notify_admin_lostMark Stapp2023-12-071-0/+20
|\ | | | | zebra: Fix non-notification of better admin won
| * zebra: Fix non-notification of better admin wonDonald Sharp2023-11-291-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If there happens to be a entry in the zebra rib that has a lower admin distance then a newly received re, zebra would not notify the upper level protocol about this happening. Imagine a case where there is a connected route for say a /32 and bgp receives a route from a peer that is the same route as the connected. Since BGP has no network statement and perceives the route as being `good` bgp will install the route into zebra. Zebra will look at the new bgp re and correctly identify that the re is not something that it will use and do nothing. This change notices this and sends up a BETTER_ADMIN_WON route notification. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | Merge pull request #12600 from donaldsharp/local_routesRuss White2023-12-051-25/+54
|\ \ | |/ |/| *: Introduce Local Host Routes to FRR
| * *: Introduce Local Host Routes to FRRDonald Sharp2023-11-011-25/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create Local routes in FRR: S 0.0.0.0/0 [1/0] via 192.168.119.1, enp39s0, weight 1, 00:03:46 K>* 0.0.0.0/0 [0/100] via 192.168.119.1, enp39s0, 00:03:51 O 192.168.119.0/24 [110/100] is directly connected, enp39s0, weight 1, 00:03:46 C>* 192.168.119.0/24 is directly connected, enp39s0, 00:03:51 L>* 192.168.119.224/32 is directly connected, enp39s0, 00:03:51 O 192.168.119.229/32 [110/100] via 0.0.0.0, enp39s0 inactive, weight 1, 00:03:46 C>* 192.168.119.229/32 is directly connected, enp39s0, 00:03:46 Create ability to redistribute local routes. Modify tests to support this change. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | zebra: On shutdown, ensure ctx's in rib_dplane_q are freedDonald Sharp2023-11-211-1/+15
| | | | | | | | | | | | | | | | | | | | a) Rename rib_init to zebra_rib_init() to better follow how things are named b) on shutdown cycle through the rib_dplane_q and free up any contexts sitting in it. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | zebra: reduce number of switch statements with dplane opcodesMark Stapp2023-11-171-60/+2
| | | | | | | | | | | | | | | | Replace several switch blocks that contain every dplane opcode with simpler sets of if()s. In these cases the code only uses a couple of opcodes. Signed-off-by: Mark Stapp <mjs@labn.net>
* | *: Move distance related defines into their own headerDonald Sharp2023-11-071-0/+1
| | | | | | | | Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | *: Remove netlink headers from lib/zebra.hDonald Sharp2023-11-071-0/+4
|/ | | | | | | | | | | | The headers associated with netlink code really only belong in those that need it. Move these headers out of lib/zebra.h and into more appropriate places. bgp's usage of the RT_TABLE_XXX defines are probably not appropriate and will be cleaned up in future commits. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* zebra: add redistribute table-direct supportPhilippe Guibert2023-10-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Redistributing routes from a specific routing table to a particular routing protocol necessitates copying route entries to the main routing table using the "ip import-table" command. Once copied, these routes are assigned a distinct "table" route type, which the "redistribute table" command of the routing protocol then picks up. For illustration, here is a configuration that showcases the use of "import-table" and "redistribute": > # show running-config > [..] > ip route 172.31.0.10/32 172.31.1.10 table 100 > router bgp 65500 > address-family ipv4 unicast > redistribute table 100 > exit-address-family > exit > ip import-table 100 > > # show ip route vrf default > [..] > T[100]>* 172.31.0.10/32 [15/0] via 172.31.1.10, r2-eth1, weight 1, 00:00:05 However, this method has inherent constraints: - The 'import-table' parameter only handles route table id up to 252. The 253/254/255 table ids are reserved in the linux system, and adding other table IDs above 255 leads to a design issue, where the size of some tables is directly related to the maximum number of table ids to support. - Duplicated route entries might interfere with original default table routes, leading to potential conflicts. There is no guarantee that the zebra RIB will favor these duplicated entries during redistribution. - There are cases where the table ID can be checked independently of the default routing table, as seen in Linux where the "ip rule" command is able to divert traffic to that routing table. In that case, there is no need to duplicate route entries in the default routing table. To overcome these issues, a new redistribution type is proposed to redistribute route entries directly from a specified routing table, eliminating the need for an initial import into the default table. Add a 'ZEBRA_ROUTE_TABLE_DIRECT' type to the 'REDISTRIBUTE' ZAPI messages. It allows sending routes from a given non default table ID from zebra to a routing daemon. The destination routing protocol table must be the default table. The redistributed route inherit from the default distance value of 14: this is the distance value reserved for routes redistributed via ROUTE_TABLE_DIRECT. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* Merge pull request #14561 from idryzhov/implicit-fallthroughDonald Sharp2023-10-131-2/+1
|\ | | | | build: add -Wimplicit-fallthrough
| * build: add -Wimplicit-fallthroughIgor Ryzhov2023-10-121-2/+1
| | | | | | | | | | | | | | | | | | | | Also: - replace all /* fallthrough */ comments with portable fallthrough; pseudo keyword to accomodate both gcc and clang - add missing break; statements as required by older versions of gcc - cleanup some code to remove unnecessary fallthrough Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
* | Merge pull request #13340 from leonshaw/fix/rib-del-connectedDonald Sharp2023-10-131-3/+4
|\ \ | |/ |/| zebra: Fix connected route deletion when multiple entry exists
| * zebra: Fix connected route deletion when multiple entry existsXiao Liang2023-04-201-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When multiple interfaces have addresses in the same network, deleting one of them may cause the wrong connected route being deleted. For example: ip link add veth1 type veth peer veth2 ip link set veth1 up ip link set veth2 up ip addr add dev veth1 192.168.0.1/24 ip addr add dev veth2 192.168.0.2/24 ip addr flush dev veth1 Zebra deletes the route of interface veth2 rather than veth1. Should match nexthop against ere->re_nhe instead of ere->re->nhe. Signed-off-by: Xiao Liang <shaw.leon@gmail.com>
* | zebra: Fix zebra crash when replacing NHE during shutdownRajasekar Raja2023-08-311-4/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During replace of a NHE from upper proto in zebra_nhg_proto_add(), - rib_handle_nhg_replace() is invoked with old NHE where we walk all RNs/REs & replace the re->nhe whose address points to old NHE. - In this walk, if prev re->nhe refcnt is decremented to 0, we free up the memory which the old NHE is pointing to. Later in zebra_nhg_proto_add(), we end up accessing this freed memory and crash. Logs: 1380766 2023/08/16 22:34:11.994671 ZEBRA: [WDEB1-93HCZ] zebra_nhg_decrement_ref: nhe 0x56091d890840 (70312519[2756/2762/2810]) 2 => 1 1380773 2023/08/16 22:34:11.994678 ZEBRA: [WDEB1-93HCZ] zebra_nhg_decrement_ref: nhe 0x56091d890840 (70312519[2756/2762/2810]) 1 => 0 1380777 2023/08/16 22:34:11.994844 ZEBRA: [JE46R-G2NEE] zebra_nhg_release: nhe 0x56091d890840 (70312519[2756/2762/2810]) 1380778 2023/08/16 22:34:11.994849 ZEBRA: [SCDBM-4H062] zebra_nhg_free: nhe 0x56091d890840 (70312519[2756/2762/2810]), refcnt 0 1380782 2023/08/16 22:34:11.995000 ZEBRA: [SCDBM-4H062] zebra_nhg_free: nhe 0x56091d890840 (0[]), refcnt 0 1380783 2023/08/16 22:34:11.995011 ZEBRA: lib/memory.c:84: mt_count_free(): assertion (mt->n_alloc) failed Backtrace: 0  0x00007f833f5f48eb in raise () from /lib/x86_64-linux-gnu/libc.so.6 1  0x00007f833f5df535 in abort () from /lib/x86_64-linux-gnu/libc.so.6 2  0x00007f833f636648 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 3  0x00007f833f63cd6a in ?? () from /lib/x86_64-linux-gnu/libc.so.6 4  0x00007f833f63cfb4 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 5  0x00007f833f63fbc8 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 6  0x00007f833f64172a in malloc () from /lib/x86_64-linux-gnu/libc.so.6 7  0x00007f833f6c3fd2 in backtrace_symbols () from /lib/x86_64-linux-gnu/libc.so.6 8  0x00007f833f9013fc in zlog_backtrace_sigsafe (priority=priority@entry=2, program_counter=program_counter@entry=0x7f833f5f48eb <raise+267>) at lib/log.c:222 9  0x00007f833f901593 in zlog_signal (signo=signo@entry=6, action=action@entry=0x7f833f988ee8 "aborting...", siginfo_v=siginfo_v@entry=0x7ffee1ce4a30,     program_counter=program_counter@entry=0x7f833f5f48eb <raise+267>) at lib/log.c:154 10 0x00007f833f92dbd1 in core_handler (signo=6, siginfo=0x7ffee1ce4a30, context=<optimized out>) at lib/sigevent.c:254 11 <signal handler called> 12 0x00007f833f5f48eb in raise () from /lib/x86_64-linux-gnu/libc.so.6 13 0x00007f833f5df535 in abort () from /lib/x86_64-linux-gnu/libc.so.6 14 0x00007f833f958f96 in _zlog_assert_failed (xref=xref@entry=0x7f833f9e4080 <_xref.10705>, extra=extra@entry=0x0) at lib/zlog.c:680 15 0x00007f833f905400 in mt_count_free (mt=0x7f833fa02800 <MTYPE_NH_LABEL>, ptr=0x51) at lib/memory.c:84 16 mt_count_free (ptr=0x51, mt=0x7f833fa02800 <MTYPE_NH_LABEL>) at lib/memory.c:80 17 qfree (mt=0x7f833fa02800 <MTYPE_NH_LABEL>, ptr=0x51) at lib/memory.c:140 18 0x00007f833f90799c in nexthop_del_labels (nexthop=nexthop@entry=0x56091d776640) at lib/nexthop.c:563 19 0x00007f833f907b91 in nexthop_free (nexthop=0x56091d776640) at lib/nexthop.c:393 20 0x00007f833f907be8 in nexthops_free (nexthop=<optimized out>) at lib/nexthop.c:408 21 0x000056091c21aa76 in zebra_nhg_free_members (nhe=0x56091d890840) at zebra/zebra_nhg.c:1628 22 zebra_nhg_free (nhe=0x56091d890840) at zebra/zebra_nhg.c:1628 23 0x000056091c21bab2 in zebra_nhg_proto_add (id=<optimized out>, type=9, instance=<optimized out>, session=0, nhg=nhg@entry=0x56091d7da028, afi=afi@entry=AFI_UNSPEC)     at zebra/zebra_nhg.c:3532 24 0x000056091c22bc4e in process_subq_nhg (lnode=0x56091d88c540) at zebra/zebra_rib.c:2689 25 process_subq (qindex=META_QUEUE_NHG, subq=0x56091d24cea0) at zebra/zebra_rib.c:3290 26 meta_queue_process (dummy=<optimized out>, data=0x56091d24d4c0) at zebra/zebra_rib.c:3343 27 0x00007f833f9492c8 in work_queue_run (thread=0x7ffee1ce55a0) at lib/workqueue.c:285 28 0x00007f833f93f60d in thread_call (thread=thread@entry=0x7ffee1ce55a0) at lib/thread.c:2008 29 0x00007f833f8f9888 in frr_run (master=0x56091d068660) at lib/libfrr.c:1223 30 0x000056091c1b8366 in main (argc=12, argv=0x7ffee1ce5988) at zebra/main.c:551 Issue: 3492162 Ticket# 3492162 Signed-off-by: Chirag Shah <chirag@nvidia.com> Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
* | Merge pull request #14256 from rodecker/rt-table-idDonald Sharp2023-08-251-1/+1
|\ \ | | | | | | zebra: Make main routing table (RT_TABLE_MAIN) configurable
| * | zebra: Make main routing table (RT_TABLE_MAIN) configurableMartin Pels2023-08-221-1/+1
| | | | | | | | | | | | Signed-off-by: Martin Pels <mpels@ripe.net>
* | | zebra: fix assert in process_subq_routePavel Ivashchenko2023-08-091-4/+18
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bug is reporoduced in case of switching interfaces betwean VRFs. ospf6d is enabled and configured in each VRF. 'dest' can be removed from the route node in the time when the same route node waiting processing in another sub-queue. A route node must only be in one sub-queue at a time. Details: 1. Config: interface if0 ipv6 address 2001:db8:cafe:2::2/64 ipv6 nat inside ipv6 ospf6 area 0.0.0.51 ipv6 ospf6 cost 10 vrf test2 exit ! interface if1 ipv6 address 2001:db8:cafe:4::1/64 ipv6 nat outside ipv6 ospf6 area 0.0.0.0 ipv6 ospf6 cost 10 vrf test2 exit ! router ospf6 ospf6 router-id 2.2.2.2 exit ! router ospf6 vrf test1 ospf6 router-id 2.2.2.2 exit ! router ospf6 vrf test2 ospf6 router-id 2.2.2.2 exit I just quickly switched interfaces between different VRFs (default/test1/test2). 2. Log messages: Aug 02 16:51:56 ubuntu zebra[386985]: [MFYWV-KH3MC] process_subq_early_route_add: (0:?):2001:db8:cafe:2::/64: Inserting route rn 0x56267593de90, re 0x56267595ae40 (connected) existing 0x0, same_count 0 Aug 02 16:51:56 ubuntu zebra[386985]: [Q4T2G-E2SQF] process_subq_early_route_add: dumping RE entry 0x56267595ae40 for 2001:db8:cafe:2::/64 vrf default(0) Aug 02 16:51:56 ubuntu zebra[386985]: [GCGMT-SQR82] rib_link: (0:?):2001:db8:cafe:2::/64: rn 0x56267593de90 adding dest Aug 02 16:51:56 ubuntu zebra[386985]: [JF0K0-DVHWH] rib_meta_queue_add: (0:254):2001:db8:cafe:2::/64: queued rn 0x56267593de90 into sub-queue Connected Routes Aug 02 16:51:56 ubuntu zebra[386985]: [QE6V0-J8BG5] rib_delnode: (0:254):2001:db8:cafe:2::/64: rn 0x56267593de90, re 0x56267595ae40, removing Aug 02 16:51:56 ubuntu zebra[386985]: [KMPGN-JBRKW] rib_meta_queue_add: (0:254):2001:db8:cafe:2::/64: rn 0x56267593de90 is already queued in sub-queue Connected Routes Aug 02 16:51:56 ubuntu zebra[386985]: [MFYWV-KH3MC] process_subq_early_route_add: (0:254):2001:db8:cafe:2::/64: Inserting route rn 0x56267593de90, re 0x56267595abf0 (ospf6) existing 0x0, same_count 1 Aug 02 16:51:56 ubuntu zebra[386985]: [Q4T2G-E2SQF] process_subq_early_route_add: dumping RE entry 0x56267595abf0 for 2001:db8:cafe:2::/64 vrf default(0) Aug 02 16:51:56 ubuntu zebra[386985]: [KMPGN-JBRKW] rib_meta_queue_add: (0:254):2001:db8:cafe:2::/64: rn 0x56267593de90 is already queued in sub-queue Connected Routes Aug 02 16:51:56 ubuntu zebra[386985]: [YEYFX-TDSC2] process_subq_early_route_add: (0:254):2001:db8:cafe:2::/64: rn 0x56267593de90, removing unneeded re 0x56267595ae40 Aug 02 16:51:56 ubuntu zebra[386985]: [Y53JX-CBC5H] rib_unlink: (0:254):2001:db8:cafe:2::/64: rn 0x56267593de90, re 0x56267595ae40 Aug 02 16:51:56 ubuntu zebra[386985]: [QE6V0-J8BG5] rib_delnode: (0:254):2001:db8:cafe:2::/64: rn 0x56267593de90, re 0x56267595abf0, removing Aug 02 16:51:56 ubuntu zebra[386985]: [JF0K0-DVHWH] rib_meta_queue_add: (0:254):2001:db8:cafe:2::/64: queued rn 0x56267593de90 into sub-queue RIP/OSPF/ISIS/EIGRP/NHRP Routes Aug 02 16:51:56 ubuntu zebra[386985]: [NZNZ4-7P54Y] default(0:254):2001:db8:cafe:2::/64: Processing rn 0x56267593de90 Aug 02 16:51:56 ubuntu zebra[386985]: [ZJVZ4-XEGPF] default(0:254):2001:db8:cafe:2::/64: Examine re 0x56267595abf0 (ospf6) status: Removed Changed flags: None dist 110 metric 10 Aug 02 16:51:56 ubuntu zebra[386985]: [NM15X-X83N9] rib_process: (0:254):2001:db8:cafe:2::/64: rn 0x56267593de90, removing re 0x56267595abf0 Aug 02 16:51:56 ubuntu zebra[386985]: [Y53JX-CBC5H] rib_unlink: (0:254):2001:db8:cafe:2::/64: rn 0x56267593de90, re 0x56267595abf0 Aug 02 16:51:56 ubuntu zebra[386985]: [KT8QQ-45WQ0] rib_gc_dest: (0:?):2001:db8:cafe:2::/64: removing dest from table Aug 02 16:51:56 ubuntu zebra[386985]: [HH6N2-PDCJS] default(0:0):2001:db8:cafe:2::/64 rn 0x56267593de90 dequeued from sub-queue Connected Routes 3. ...and then assert: (gdb) bt #0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=140662163115136) at ./nptl/pthread_kill.c:44 #1 __pthread_kill_internal (signo=6, threadid=140662163115136) at ./nptl/pthread_kill.c:78 #2 __GI___pthread_kill (threadid=140662163115136, signo=signo@entry=6) at ./nptl/pthread_kill.c:89 #3 0x00007fee76753476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #4 0x00007fee767397f3 in __GI_abort () at ./stdlib/abort.c:79 #5 0x00007fee76a420fd in _zlog_assert_failed () from target:/usr/lib/x86_64-linux-gnu/frr/libfrr.so.0 #6 0x0000562674efe0f0 in process_subq_route (qindex=7 '\a', lnode=0x562675940c60) at zebra/zebra_rib.c:2540 #7 process_subq (qindex=META_QUEUE_NOTBGP, subq=0x562675574580) at zebra/zebra_rib.c:3055 #8 meta_queue_process (dummy=<optimized out>, data=0x56267556d430) at zebra/zebra_rib.c:3091 #9 0x00007fee76a386e8 in work_queue_run () from target:/usr/lib/x86_64-linux-gnu/frr/libfrr.so.0 #10 0x00007fee76a31c91 in thread_call () from target:/usr/lib/x86_64-linux-gnu/frr/libfrr.so.0 #11 0x00007fee769ee528 in frr_run () from target:/usr/lib/x86_64-linux-gnu/frr/libfrr.so.0 #12 0x0000562674e97ec5 in main (argc=5, argv=0x7ffd1e275958) at zebra/main.c:478 (gdb) print lnode->data $10 = (void *) 0x56267593de90 (gdb) p/x *(struct route_node *)0x56267593de90 $11 = { p = { family = 0xa, prefixlen = 0x40, u = { prefix = 0x20, prefix4 = { s_addr = 0xb80d0120 }, prefix6 = { __in6_u = { __u6_addr8 = {0x20, 0x1, 0xd, 0xb8, 0xca, 0xfe, 0x0, 0x2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, __u6_addr16 = {0x120, 0xb80d, 0xfeca, 0x200, 0x0, 0x0, 0x0, 0x0}, __u6_addr32 = {0xb80d0120, 0x200feca, 0x0, 0x0} } }, ... table = 0x5626755ae010, parent = 0x5626755ae070, link = {0x0, 0x0}, lock = 0x4, nodehash = { hi = { next = 0x5626755ae0d0, hashval = 0xebe8bdbf } }, info = 0x0 3. What's happen: We removed unneeded re 0x56267595ae40 while adding re 0x56267595abf0. It was the last connected re, but rn 0x56267593de90 is still in the connected sub-queue. Then rib_delnode was called for 0x56267595abf0. (rn 0x56267593de90 is still in the connected sub-queue). rib_delnode have called rib_meta_queue_add which have checked, that rn is absent in sub-queue RIP/OSPF/ISIS/EIGRP/NHRP and have added rn in the second sub-queue. Fixes: d7ac4c4d88 ("zebra: Introduce early route processing on the MetaQ") Signed-off-by: Pavel Ivashchenko <pivashchenko@nfware.com>
* | lib, zebra: Fix EVPN nexthop config orderXiao Liang2023-07-271-0/+18
| | | | | | | | | | | | | | Delay EVPN route addition to synchronize with rib_delete(), which now uses early route queue. Signed-off-by: Xiao Liang <shaw.leon@gmail.com>
* | zebra: add several fields for debuganlan_cs2023-07-251-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Two changes for debug: 1. Add a field to indicate its vrf for nexthop. When the interface changes vrf, we can't easily know the vrf of this nexthop according to current log. 2. Add a field to indicate operation type. We can't know whether to add or remove route according to current log. Before: ``` zebra_nhg_increment_ref: nhe 0x555623eb82c0 (76[if 6]) 0 => 1 zebra_interface_nhg_reinstall install nhe 75[77.75.1.75 if 6] nh type 3 flags 0x1 Route 77.75.1.0/24(8) queued for processing into sub-queue Early Route Processing Route 77.75.1.0/24(8) queued for processing into sub-queue Early Route Processing ``` After: ``` zebra_nhg_increment_ref: nhe 0x555623eb82c0 (76[if 6 vrfid 9]) 0 => 1 zebra_interface_nhg_reinstall install nhe 75[77.75.1.75 if 6 vrfid 8] nh type 3 flags 0x1 Route 77.75.1.0/24(8) (add) queued for processing into sub-queue Early Route Processing Route 77.75.1.0/24(8) (delete) queued for processing into sub-queue Early Route Processing ``` Signed-off-by: anlan_cs <anlan_cs@tom.com>
* | zebra: Further handle route replace semanticsDonald Sharp2023-07-171-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When an upper level protocol is installing a route X that needs to be route replaced and at the same time the same or another protocol installs a different route that depends on route X for nexthop resolution can leave us with a state where the route is not accepted because zebra is still really early in the route replace semantics ( route X is still on the work Queue to be processed ) then the dependent route would not be installed. This came up in the bgp_default_originate test cases frequently. Further extendd the ROUTE_ENTR_ROUTE_REPLACING flag to cover this case as well. This has come up because the early route processing queueing that was implemented late last year. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | zebra: Use zebra dplane for RTM link and addrDonald Sharp2023-07-051-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a) Move the reads of link and address information into the dplane b) Move the startup read of data into the dplane as well. c) Break up startup reading of the linux kernel data into multiple phases. As that we have implied ordering of data that must be read first and if the dplane has taken over some data reading then we must delay initial read-in of other data. Fixes: #13288 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | zebra: Add code to get/set interface to pass up from dplaneDonald Sharp2023-07-051-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | 1) Add a bunch of get/set functions and associated data structure in zebra_dplane to allow the setting and retrieval of interface netlink data up into the master pthread. 2) Add a bit of code to breakup startup into stages. This is because FRR currently has a mix of dplane and non dplane interactions and the code needs to be paused before continuing on. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | Merge pull request #13875 from donaldsharp/static_dplane_issuesMark Stapp2023-07-051-8/+7
|\ \ | | | | | | zebra: Static routes async notification do not need this test
| * | zebra: Static routes async notification do not need this testDonald Sharp2023-06-291-8/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When using asic_offload with an asynchronous notification the rib_route_match_ctx function is testing for distance and tag being correct against the re. Normal route notification for static routes is this(well really all routes): a) zebra dplane generates a ctx to send to the dplane for route install b) dplane installs it in the kernel c) if the dplane_fpm_nl.c module is being used it installs it. d) The context's success code is set to it worked and passes the context back up to zebra for processing. e) Zebra master receives this and checks the distance and tag are correct for static routes and accepts the route and marks it installed. If the operator is using a wait for install mechansim where the dplane is asynchronously sending the result back up at a future time *and* it is using the dplane_fpm_nl.c code where it uses the rt_netlink.c route parsing code, then there is no way to set distance as that we do not pass distance to the kernel. As such static routes were never being properly handled since the re and context would not match and the route would still be marked as queued. Modify the code such that the asynchronous path notification for static routes ignores the distance and tag's as that there is no way to test for this data from that path at this point in time. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | | zebra: Dump route details when deleting a routeDonatas Abraitis2023-06-291-2/+6
|/ / | | | | | | | | | | Just more details what's going on when deleting a route. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
* / zebra: Reduce creation and fix memory leak of frrscripting pointersDonald Sharp2023-05-051-17/+20
|/ | | | | | | | | | | | | | | | | | | There are two issues being addressed: a) The ZEBRA_ON_RIB_PROCESS_HOOK_CALL script point was creating a fs pointer per dplane ctx in rib_process_dplane_results(). b) The fs pointer was not being deleted and directly leaked. For (a) Move the creation of the fs to outside the do while loop. For (b) At function end ensure that the pointer is actually deleted. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* zebra: Actually free up memory associated with the mq listDonald Sharp2023-04-121-0/+3
| | | | | | | Free up the link list data structures as well as properly account for data sizes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* Merge pull request #13145 from donaldsharp/do_deleteJafar Al-Gharaibeh2023-04-051-1/+71
|\ | | | | Improve and fix zebra GR
| * zebra: Ensure gr events run after Meta Queue has runDonald Sharp2023-03-301-1/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BGP signals to zebra that a afi has converged immediately after it has finished processing all routes for a given afi/safi. This generates events in zebra in this order a) Routes received from BGP, placed on early-rib Meta-Q b) Signal GR for the afi. Now imagine that zebra reads GR code and immediately processes routes that are in the actual rib and removes some routes. This generates a c) route deletion to the kernel for some number of routes that may be in the the early-rib Meta-Q d) Process the Meta-Q, and re-install the routes This is undesirable behavior in zebra. In that while we may end up in a correct state, there will be a blip for some number of routes that happen to be in the early rib Meta-Q. Modify the GR code to have it's own processing entry at the end of the Meta-Q. This will allow all routes to be processed and ready for handling by the Graceful Restart code. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | zebra: Cleanup ctx leak on shutdown and turn off eventDonald Sharp2023-03-311-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | two things: On shutdown cleanup any events associated with the update walker. Also do not allow new events to be created. Fixes this mem-leak: ./msdp_topo1.test_msdp_topo1/r2.zebra.asan.1117790:Direct leak of 8 byte(s) in 1 object(s) allocated from: ./msdp_topo1.test_msdp_topo1/r2.zebra.asan.1117790- #0 0x7f0dd0b08037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 ./msdp_topo1.test_msdp_topo1/r2.zebra.asan.1117790- #1 0x7f0dd06c19f9 in qcalloc lib/memory.c:105 ./msdp_topo1.test_msdp_topo1/r2.zebra.asan.1117790- #2 0x55b42fb605bc in rib_update_ctx_init zebra/zebra_rib.c:4383 ./msdp_topo1.test_msdp_topo1/r2.zebra.asan.1117790- #3 0x55b42fb6088f in rib_update zebra/zebra_rib.c:4421 ./msdp_topo1.test_msdp_topo1/r2.zebra.asan.1117790- #4 0x55b42fa00344 in netlink_link_change zebra/if_netlink.c:2221 ./msdp_topo1.test_msdp_topo1/r2.zebra.asan.1117790- #5 0x55b42fa24622 in netlink_information_fetch zebra/kernel_netlink.c:399 ./msdp_topo1.test_msdp_topo1/r2.zebra.asan.1117790- #6 0x55b42fa28c02 in netlink_parse_info zebra/kernel_netlink.c:1183 ./msdp_topo1.test_msdp_topo1/r2.zebra.asan.1117790- #7 0x55b42fa24951 in kernel_read zebra/kernel_netlink.c:493 ./msdp_topo1.test_msdp_topo1/r2.zebra.asan.1117790- #8 0x7f0dd0797f0c in event_call lib/event.c:1995 ./msdp_topo1.test_msdp_topo1/r2.zebra.asan.1117790- #9 0x7f0dd0684fd9 in frr_run lib/libfrr.c:1185 ./msdp_topo1.test_msdp_topo1/r2.zebra.asan.1117790- #10 0x55b42fa30caa in main zebra/main.c:465 ./msdp_topo1.test_msdp_topo1/r2.zebra.asan.1117790- #11 0x7f0dd01b5d09 in __libc_start_main ../csu/libc-start.c:308 ./msdp_topo1.test_msdp_topo1/r2.zebra.asan.1117790- ./msdp_topo1.test_msdp_topo1/r2.zebra.asan.1117790-SUMMARY: AddressSanitizer: 8 byte(s) leaked in 1 allocation(s). Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | zebra: Use zebra_vrf_lookup_by_id when we canDonald Sharp2023-03-281-5/+5
|/ | | | | | Let's make this as consistent as is possible. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* *: Convert event.h to frrevent.hDonald Sharp2023-03-241-1/+1
| | | | | | | We should probably prevent any type of namespace collision with something else. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* *: Convert THREAD_XXX macros to EVENT_XXX macrosDonald Sharp2023-03-241-1/+1
| | | | Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* *: Convert a bunch of thread_XX to event_XXDonald Sharp2023-03-241-1/+1
| | | | | | | | | | | | | Convert these functions: thread_getrusage thread_cmd_init thread_consumed_time thread_timer_to_hhmmss thread_is_scheduled thread_ignore_late_timer Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* *: Convert thread_add_XXX functions to event_add_XXXDonald Sharp2023-03-241-4/+4
| | | | Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* *: Rename `struct thread` to `struct event`Donald Sharp2023-03-241-5/+5
| | | | | | | | | 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>
* *: Rename thread.[ch] to event.[ch]Donald Sharp2023-03-241-1/+1
| | | | | | | | | | | 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>
* Merge pull request #12798 from donaldsharp/rib_match_multicastRuss White2023-02-211-74/+17
|\ | | | | Rib match multicast
| * zebra: Remove code duplication for v4 and v6 versions of rib_match_multicastDonald Sharp2023-02-161-74/+17
| | | | | | | | | | | | | | a) Consolidate v4 and v6 versions of rib_match_multicast b) Improve debug to show what we matched against as well. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | Merge pull request #12818 from imzyxwvu/fix/other-table-inactiveDonald Sharp2023-02-211-5/+5
|\ \ | | | | | | zebra: Fix other table inactive when ip import-table is on
| * | zebra: Fix other table inactive when ip import-table is onzyxwvu Shi2023-02-151-5/+5
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In `rib_link`, if is_zebra_import_table_enabled returns true, `rib_queue_add` will not called, resulting in other table route node never processed. This actually should not be dependent on whether the route is imported. In `rib_delnode`, if is_zebra_import_table_enabled returns true, it will use `rib_unlink` instead of enqueuing the route node for process. There is no reason that imported route nodes should not be reprocessed. Long ago, the behaviour was dependent on whether the route_entry comes from a table other than main. Signed-off-by: zyxwvu Shi <i@shiyc.cn>
* | Merge pull request #12780 from opensourcerouting/spdx-license-idDonald Sharp2023-02-171-16/+1
|\ \ | |/ |/| *: convert to SPDX License identifiers
| * *: auto-convert to SPDX License IDsDavid Lamparter2023-02-091-16/+1
| | | | | | | | | | | | Done with a combination of regex'ing and banging my head against a wall. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* | Merge pull request #12789 from donaldsharp/version_cleanupDavid Lamparter2023-02-141-32/+69
|\ \
| * | lib, zebra: Consolidate ZEBRA_TABLE_MAX_DISTANCE valuesDonald Sharp2023-02-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Currently `ip import-table 33` imports routes with a distance of 15, as defined by zebra.h. zebra_rib.c on the other hand believes the default value for the table is 150. Let's make them agree with each other. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-03 11:04:18 +0100