summaryrefslogtreecommitdiff
path: root/zebra/zebra_rib.c
AgeCommit message (Collapse)Author
2022-01-31zebra: name the route_entry opaque struct more specificallyMark Stapp
The name 'opaque' is a little general - call the route_entry struct 're_opaque' to make it more specific. Signed-off-by: Mark Stapp <mstapp@nvidia.com>
2022-01-18zebra: Use %pRN instead of %pFX whenver possibleDonald Sharp
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-01-18zebra: Modify route_notify_internal to use a route_nodeDonald Sharp
Pass in the route_node that is under consideration into route_notify_internal to allow calling functions to reduce stack size as well as looking up data. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-01-18zebra: Cleanup %pFX to %pRN in rib_process_resultDonald Sharp
The dest_pfx was pretty much only ever used for debug output and FRR already knows the rn. So use that instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-01-18zebra: Reduce unneeded lookup in rib_processDonald Sharp
the lookup of the src_p and dest_p is not needed since the values are never used. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-01-18zebra: Reduce lookups in rib_process_dplane_notifyDonald Sharp
the dest_p and src_p values were only ever used for debugs and %pFX, when we already have the rn. There is no need to do this lookup Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-01-18zebra: Convert redistribute_update to use a route_nodeDonald Sharp
FRR is passing around a bunch of data that is encapsulated within the route node. Let's just pass that around instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com> Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-01-18zebra: Convert redistribute_delete to use a route_nodeDonald Sharp
FRR is passing around a bunch of data that is encapsulated within the route node. Let's just pass that around instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-01-13zebra: Fix for route node having no tracking NHTSarita Patra
Topology: IXIA-----(ens192)FRR(ens224)------iXIA Configuration: 1. Create 8 sub-interfaces on ens192 under Default VRF and configure 8 EBGP session between FRR and IXIA. 2. Create 1000 sub-interfaces on ens224 under Default VRF and configure 1000 EBGP session between FRR and IXIA. 3. 2M prefixes distributed from Left side Ixia each with 8 ECMP path. 4. So in total, there are 2M prefixes * 8 ECMP = 16M prefixes entries in RIB and FIB. Issue: Shut ens192 and ens224, this is taking 1hr 15 mins to clean up the routes. Root Cause: In the case of route deletion, if the particular route node is having nht count = 0, we are going to the parent and doing nht evaluation, which is not needed. Fix: If the deleted the route node is having nht count > 0, then do a nht evaluation on the parent node. Shut ens192 and ens224, it is taking 1 min to clean up the routes with the fix. Signed-off-by: Sarita Patra <saritap@vmware.com>
2021-11-23zebra: add installed nexthop-group id valueMark Stapp
In some cases, zebra may install a nexthop-group id that is different from the id of the nhe struct attached to a route-entry. This happens for a singleton recursive nexthop, for example, where a route is installed with the resolving nexthop's id. The installed value is the most useful value - that corresponds to information in the kernel on linux/netlink platforms that support nhgs. Display both values if they differ in ascii output, and include both values in the json form. Signed-off-by: Mark Stapp <mstapp@nvidia.com>
2021-11-16*: unify if_is_loopback/if_is_loopback_or_vrfIgor Ryzhov
We should always treat the VRF interface as a loopback. Currently, this is not the case, because in some old pre-VRF code we use if_is_loopback instead of if_is_loopback_or_vrf. To avoid any future problems, the proposal is to rename if_is_loopback_or_vrf to if_is_loopback and use it everywhere. if_is_loopback is renamed to if_is_loopback_exact in case it's ever needed, but currently it's not used anywhere. Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
2021-10-28Merge pull request #9870 from opensourcerouting/zebra-rib-select-orderDonald Sharp
zebra: set SELECTED before going into dplane code
2021-10-26Merge pull request #9440 from dlqs/dplanehook2Quentin Young
2021-10-22zebra: set SELECTED before going into dplane codeDavid Lamparter
There is a bit of an impedance mismatch in the sequence of events here. Depending on the dplane behavior, the `ROUTE_ENTRY_SELECTED` bit will be inconsistent for rib_process_result(). With an asynchronous dataplane: 0. rib_process() is called 1. rib_install_kernel() is called, dplane action is queued 2. rib_install_kernel() returns 3. rib_process() sets the SELECTED bit appropriately, returns 4. dplane is done, triggers rib_process_result() 5. SELECTED bit is seen in "after" state (5a. NHT code looks at the SELECTED bit, works correctly.) With a synchronous dataplane: 0. rib_process() is called 1. rib_install_kernel() is called, dplane action is executed 2. dplane (should) trigger rib_process_result() 3. SELECTED bit is seen in "before" state (3a. NHT code looks at the SELECTED bit, fails.) 4. rib_install_kernel() returns 5. rib_process() sets the SELECTED bit appropriately, too late. Essentially, poking the dataplane is a sequencing point where control is handed over to the dplane. Control may or may not return immediately. Doing /anything/ after triggering the dataplane is a recipe for odd race conditions. (FWIW, I'm not sure rib_process_result() is called correctly in the synchronous case, but that's a separate problem.) Unfortunately, this change might have some unforeseen side effects. I haven't dug through the code to see if anything breaks. There /shouldn't/ be anything looking at the SELECTED bit here, but who knows. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2021-10-20zebra: modify rib_update to be a bit smarter about mallocDonald Sharp
rib_update() was mallocing memory then attempting to schedule and if the schedule failed( it was already going to be run ) FRR would then free the memory. Fix this memory usage pattern Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-10-20zebra: Add dplane hook pointDonald Lee
Signed-off-by: Donald Lee <dlqs@gmx.com>
2021-09-27zebra: Start carrying safi for rnh processingDonald Sharp
PIM is going to need to be able to send down the address it is trying to resolve in the multicast rib. We need a way to signal this to the end developer. Start the conversion by adding the ability to have a safi. But only allow SAFI_UNICAST at the moment. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-09-27zebra: remove 'enum rnh_type' from systemDonald Sharp
This code is now dead code since there are not two nexthop resolution types. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-09-14zebra: use the dataplane to read netlink intf addr changesMark Stapp
Read incoming interface address change notifications in the dplane pthread; enqueue the events to the main pthread for processing. This is netlink-only for now - the bsd kernel socket path remains unchanged. Signed-off-by: Mark Stapp <mjs.ietf@gmail.com>
2021-09-14zebra: add new dplane op codes for interface addr eventsMark Stapp
Add new dplane op values for incoming interface address add and delete events. Signed-off-by: Mark Stapp <mjs.ietf@gmail.com>
2021-08-12Merge pull request #9304 from donaldsharp/zebra_random_stuffMark Stapp
Zebra random stuff
2021-08-09zebra: Properly note add/update for rib_add_multipath_nheDonald Sharp
When calling rib_add_multipath_nhe ensure that we have well aligned return codes that mean something so that interersted parties can properly handle the situation. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-06zebra: Delete rib_lookup_and_dump since it is not usedDonald Sharp
The rib_lookup_and_dump function is never used, remove Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-06zebra: Remove rib_lookup_and_pushup functionDonald Sharp
The rib_lookup_and_pushup function, from what I can tell, was used more when static route processing and connected routes were more closely integrated in zebra. The goal was when we were adding a new address to remove the connected route and then allow processing of the new address. With the re-org a few years ago to seperate out connected routes as well as static routes, I believe this is no longer needed. on BSD, without this code change we have this log: 2021/08/05 14:33:38 ZEBRA: [QEVVE-G3FQQ] rib_meta_queue_add: (0:0):10.40.30.0/24: queued rn 0x802022bb0 into sub-queue 4 2021/08/05 14:33:38 ZEBRA: [ZPR30-5G1FB] Kernel: Len: 200 Type: RTM_DELETE 2021/08/05 14:33:38 ZEBRA: [V3NSB-BPKBD] Kernel: GATEWAY DONE PROTO1 2021/08/05 14:33:38 ZEBRA: [HDTM1-ENZNM] Kernel: message seq 15 2021/08/05 14:33:38 ZEBRA: [MJD4M-0AAAR] Kernel: pid 53305, rtm_addrs {DST,GATEWAY,NETMASK} 2021/08/05 14:33:38 ZEBRA: [Y9Y5K-JJ7NT] rtm_read: got rtm of type 2 (RTM_DELETE) addrs {DST,GATEWAY,NETMASK} 2021/08/05 14:33:38 ZEBRA: [V17DT-1FJEN] kernel_rtm: 10.40.30.0/24: successfully did NH 9.8.6.7 2021/08/05 14:33:38 ZEBRA: [ZPR30-5G1FB] Kernel: Len: 164 Type: RTM_NEWADDR 2021/08/05 14:33:38 ZEBRA: [V3NSB-BPKBD] Kernel: 2021/08/05 14:33:38 ZEBRA: [HDTM1-ENZNM] Kernel: message seq 4664 2021/08/05 14:33:38 ZEBRA: [MJD4M-0AAAR] Kernel: pid 0, rtm_addrs {DST} 2021/08/05 14:33:38 ZEBRA: [M09CX-TKB4N] ifam_read_mesg: ifindex 1, ifname vtnet0, ifam_addrs {NETMASK,IFP,IFA,BRD}, ifam_flags 0x0, addr 10.40.30.1/24 broad 10.40.30.255 dst (unspec) gateway (unspec) 2021/08/05 14:33:38 ZEBRA: [MFYWV-KH3MC] rib_add_multipath_nhe: (0:0):10.40.30.0/24: Inserting route rn 0x802022bb0, re 0x8032973a0 (connected) existing 0x0, same_count 0 2021/08/05 14:33:38 ZEBRA: [Q4T2G-E2SQF] rib_add_multipath_nhe: dumping RE entry 0x8032973a0 for 10.40.30.0/24 vrf default(0) 2021/08/05 14:33:38 ZEBRA: [M5M58-9PD2R] 10.40.30.0/24: uptime == 1379355, type == 2, instance == 0, table == 0 2021/08/05 14:33:38 ZEBRA: [RVZMM-N7DME] 10.40.30.0/24: metric == 1, mtu == 0, distance == 0, flags == None status == None 2021/08/05 14:33:38 ZEBRA: [Q1NW5-NWY7P] 10.40.30.0/24: nexthop_num == 1, nexthop_active_num == 0 2021/08/05 14:33:38 ZEBRA: [TFHQ8-TC30H] 10.40.30.0/24: NH vtnet0[1] vrf default(0) with flags 2021/08/05 14:33:38 ZEBRA: [SCETK-GQ9E4] 10.40.30.0/24: dump complete 2021/08/05 14:33:38 ZEBRA: [QEVVE-G3FQQ] rib_meta_queue_add: (0:0):10.40.30.0/24: queued rn 0x802022bb0 into sub-queue 2 2021/08/05 14:33:38 ZEBRA: [MFYWV-KH3MC] rib_add_multipath_nhe: (0:?):10.40.30.0/24 (MRIB): Inserting route rn 0x802022f30, re 0x803297340 (connected) existing 0x0, same_count 0 2021/08/05 14:33:38 ZEBRA: [Q4T2G-E2SQF] rib_add_multipath_nhe: dumping RE entry 0x803297340 for 10.40.30.0/24 vrf default(0) 2021/08/05 14:33:38 ZEBRA: [M5M58-9PD2R] 10.40.30.0/24: uptime == 1379355, type == 2, instance == 0, table == 0 2021/08/05 14:33:38 ZEBRA: [RVZMM-N7DME] 10.40.30.0/24: metric == 1, mtu == 0, distance == 0, flags == None status == None 2021/08/05 14:33:38 ZEBRA: [Q1NW5-NWY7P] 10.40.30.0/24: nexthop_num == 1, nexthop_active_num == 0 2021/08/05 14:33:38 ZEBRA: [TFHQ8-TC30H] 10.40.30.0/24: NH vtnet0[1] vrf default(0) with flags 2021/08/05 14:33:38 ZEBRA: [SCETK-GQ9E4] 10.40.30.0/24: dump complete 2021/08/05 14:33:38 ZEBRA: [GCGMT-SQR82] rib_link: (0:?):10.40.30.0/24 (MRIB): rn 0x802022f30 adding dest 2021/08/05 14:33:38 ZEBRA: [QEVVE-G3FQQ] rib_meta_queue_add: (0:0):10.40.30.0/24 (MRIB): queued rn 0x802022f30 into sub-queue 2 2021/08/05 14:33:38 ZEBRA: [ZPR30-5G1FB] Kernel: Len: 240 Type: RTM_ADD 2021/08/05 14:33:38 ZEBRA: [V3NSB-BPKBD] Kernel: UP PINNED 2021/08/05 14:33:38 ZEBRA: [HDTM1-ENZNM] Kernel: message seq 0 2021/08/05 14:33:38 ZEBRA: [MJD4M-0AAAR] Kernel: pid 0, rtm_addrs {DST,GATEWAY,NETMASK} 2021/08/05 14:33:38 ZEBRA: [K0KVE-2GJA1] default(0:0):10.40.30.0/24: Processing rn 0x802022bb0 2021/08/05 14:33:38 ZEBRA: [RWCK7-TX4HT] default(0:0):10.40.30.0/24: Examine re 0x8032973a0 (connected) status: Changed flags: None dist 0 metric 1 2021/08/05 14:33:38 ZEBRA: [RWCK7-TX4HT] default(0:0):10.40.30.0/24: Examine re 0x8032970a0 (static) status: None flags: Recursion RR Distance dist 1 metric 0 2021/08/05 14:33:38 ZEBRA: [NYYJJ-0Q8QG] default(0:0):10.40.30.0/24: After processing: old_selected 0x0 new_selected 0x8032973a0 old_fib 0x0 new_fib 0x8032973a0 2021/08/05 14:33:38 ZEBRA: [RT9DY-ZS2KN] default(0:0):10.40.30.0/24: Adding route rn 0x802022bb0, re 0x8032973a0 (connected) 2021/08/05 14:33:38 ZEBRA: [PP3BZ-RABJN] default(0:0):10.40.30.0/24: rn 0x802022bb0 dequeued from sub-queue 2 2021/08/05 14:33:38 ZEBRA: [K0KVE-2GJA1] default(0:0):10.40.30.0/24: Processing rn 0x802022f30 2021/08/05 14:33:38 ZEBRA: [RWCK7-TX4HT] default(0:0):10.40.30.0/24: Examine re 0x803297340 (connected) status: Changed flags: None dist 0 metric 1 2021/08/05 14:33:38 ZEBRA: [NYYJJ-0Q8QG] default(0:0):10.40.30.0/24: After processing: old_selected 0x0 new_selected 0x803297340 old_fib 0x0 new_fib 0x803297340 2021/08/05 14:33:38 ZEBRA: [RT9DY-ZS2KN] default(0:0):10.40.30.0/24: Adding route rn 0x802022f30, re 0x803297340 (connected) 2021/08/05 14:33:38 ZEBRA: [PP3BZ-RABJN] default(0:0):10.40.30.0/24: rn 0x802022f30 dequeued from sub-queue 2 2021/08/05 14:33:38 ZEBRA: [K0KVE-2GJA1] default(0:0):10.40.30.0/24: Processing rn 0x802022bb0 2021/08/05 14:33:38 ZEBRA: [RWCK7-TX4HT] default(0:0):10.40.30.0/24: Examine re 0x8032973a0 (connected) status: Queued flags: Selected dist 0 metric 1 2021/08/05 14:33:38 ZEBRA: [RWCK7-TX4HT] default(0:0):10.40.30.0/24: Examine re 0x8032970a0 (static) status: None flags: Recursion RR Distance dist 1 metric 0 2021/08/05 14:33:38 ZEBRA: [NYYJJ-0Q8QG] default(0:0):10.40.30.0/24: After processing: old_selected 0x8032973a0 new_selected 0x8032973a0 old_fib 0x8032973a0 new_fib 0x8032973a0 2021/08/05 14:33:38 ZEBRA: [PP3BZ-RABJN] default(0:0):10.40.30.0/24: rn 0x802022bb0 dequeued from sub-queue 4 2021/08/05 14:33:38 ZEBRA: [GHWHS-ZKQM5] update_from_ctx: default(0:0):10.40.30.0/24: SELECTED, re 0x8032973a0 2021/08/05 14:33:38 ZEBRA: [TS3SH-1276M] default(0:0):10.40.30.0/24 update_from_ctx(): no fib nhg 2021/08/05 14:33:38 ZEBRA: [HKQXC-4STSK] default(0:0):10.40.30.0/24 update_from_ctx(): rib nhg matched, changed 'false' 2021/08/05 14:33:38 ZEBRA: [HBZNK-5H1X0] (0:0):10.40.30.0/24: Redist update re 0x8032973a0 (connected), old 0x0 (None) 2021/08/05 14:33:38 ZEBRA: [GHWHS-ZKQM5] update_from_ctx: default(0:0):10.40.30.0/24: SELECTED, re 0x8032973a0 2021/08/05 14:33:38 ZEBRA: [TS3SH-1276M] default(0:0):10.40.30.0/24 update_from_ctx(): no fib nhg 2021/08/05 14:33:38 ZEBRA: [HKQXC-4STSK] default(0:0):10.40.30.0/24 update_from_ctx(): rib nhg matched, changed 'false' 2021/08/05 14:33:38 ZEBRA: [HBZNK-5H1X0] (0:0):10.40.30.0/24: Redist update re 0x8032973a0 (connected), old 0x0 (None) With this code change: 2021/08/05 14:41:24 ZEBRA: [MFYWV-KH3MC] rib_add_multipath_nhe: (0:?):10.10.40.0/24: Inserting route rn 0x802022f30, re 0x8021cbe60 (static) existing 0x0, same_count 0 2021/08/05 14:41:24 ZEBRA: [RT9DY-ZS2KN] default(0:0):10.10.40.0/24: Adding route rn 0x802022f30, re 0x8021cbe60 (static) 2021/08/05 14:41:24 ZEBRA: [V17DT-1FJEN] kernel_rtm: 10.10.40.0/24: successfully did NH 9.8.6.7 2021/08/05 14:41:24 ZEBRA: [ZPR30-5G1FB] Kernel: Len: 200 Type: RTM_ADD 2021/08/05 14:41:24 ZEBRA: [V3NSB-BPKBD] Kernel: UP GATEWAY DONE PROTO1 2021/08/05 14:41:24 ZEBRA: [HDTM1-ENZNM] Kernel: message seq 0 2021/08/05 14:41:24 ZEBRA: [MJD4M-0AAAR] Kernel: pid 60818, rtm_addrs {DST,GATEWAY,NETMASK} 2021/08/05 14:41:24 ZEBRA: [Y9Y5K-JJ7NT] rtm_read: got rtm of type 1 (RTM_ADD) addrs {DST,GATEWAY,NETMASK} 2021/08/05 14:41:24 ZEBRA: [TS3SH-1276M] default(0:0):10.10.40.0/24 update_from_ctx(): no fib nhg 2021/08/05 14:41:24 ZEBRA: [HKQXC-4STSK] default(0:0):10.10.40.0/24 update_from_ctx(): rib nhg matched, changed 'true' 2021/08/05 14:41:24 ZEBRA: [HBZNK-5H1X0] (0:0):10.10.40.0/24: Redist update re 0x8021cbe60 (static), old 0x0 (None) 2021/08/05 14:42:06 ZEBRA: [ZJ4AV-JEMJ3] dplane_intf_addr_set 2021/08/05 14:42:06 ZEBRA: [ZPR30-5G1FB] Kernel: Len: 164 Type: RTM_NEWADDR 2021/08/05 14:42:06 ZEBRA: [V3NSB-BPKBD] Kernel: 2021/08/05 14:42:06 ZEBRA: [HDTM1-ENZNM] Kernel: message seq 4664 2021/08/05 14:42:06 ZEBRA: [MJD4M-0AAAR] Kernel: pid 0, rtm_addrs {DST} 2021/08/05 14:42:06 ZEBRA: [M09CX-TKB4N] ifam_read_mesg: ifindex 1, ifname vtnet0, ifam_addrs {NETMASK,IFP,IFA,BRD}, ifam_flags 0x0, addr 10.10.40.3/24 broad 10.10.40.255 dst (unspec) gateway (unspec) 2021/08/05 14:42:06 ZEBRA: [MFYWV-KH3MC] rib_add_multipath_nhe: (0:0):10.10.40.0/24: Inserting route rn 0x802022f30, re 0x80308c4c0 (connected) existing 0x0, same_count 0 2021/08/05 14:42:06 ZEBRA: [MFYWV-KH3MC] rib_add_multipath_nhe: (0:?):10.10.40.0/24 (MRIB): Inserting route rn 0x802023160, re 0x80308c460 (connected) existing 0x0, same_count 0 2021/08/05 14:42:06 ZEBRA: [ZPR30-5G1FB] Kernel: Len: 240 Type: RTM_ADD 2021/08/05 14:42:06 ZEBRA: [V3NSB-BPKBD] Kernel: UP PINNED 2021/08/05 14:42:06 ZEBRA: [HDTM1-ENZNM] Kernel: message seq 0 2021/08/05 14:42:06 ZEBRA: [MJD4M-0AAAR] Kernel: pid 0, rtm_addrs {DST,GATEWAY,NETMASK} 2021/08/05 14:42:06 ZEBRA: [RG9Y6-E93A0] default(0:0):10.10.40.0/24: Updating route rn 0x802022f30, re 0x80308c4c0 (connected) old 0x8021cbe60 (static) 2021/08/05 14:42:06 ZEBRA: [RT9DY-ZS2KN] default(0:0):10.10.40.0/24: Adding route rn 0x802023160, re 0x80308c460 (connected) 2021/08/05 14:42:06 ZEBRA: [THSYN-E2XFY][EC 100663299] rtm_write: write : Address already in use (48) 2021/08/05 14:42:06 ZEBRA: [RV5F2-MQGZG][EC 100663303] kernel_rtm: 10.10.40.0/24: rtm_write() unexpectedly returned -5 for command RTM_DELETE 2021/08/05 14:42:06 ZEBRA: [ZPR30-5G1FB] Kernel: Len: 200 Type: RTM_DELETE 2021/08/05 14:42:06 ZEBRA: [V3NSB-BPKBD] Kernel: UP PROTO1 2021/08/05 14:42:06 ZEBRA: [HDTM1-ENZNM] Kernel: message seq 1 2021/08/05 14:42:06 ZEBRA: [MJD4M-0AAAR] Kernel: pid 60818, rtm_addrs {DST,GATEWAY,NETMASK} 2021/08/05 14:42:06 ZEBRA: [XASXT-GF69Y] kernel_rtm: No useful nexthops were found in RIB prefix 10.10.40.0/24 2021/08/05 14:42:06 ZEBRA: [TS3SH-1276M] default(0:0):10.10.40.0/24 update_from_ctx(): no fib nhg 2021/08/05 14:42:06 ZEBRA: [HKQXC-4STSK] default(0:0):10.10.40.0/24 update_from_ctx(): rib nhg matched, changed 'false' 2021/08/05 14:42:06 ZEBRA: [HBZNK-5H1X0] (0:0):10.10.40.0/24: Redist update re 0x80308c4c0 (connected), old 0x8021cbe60 (static) netstat -rn: 10.10.40.0/24 link#1 U vtnet0 10.10.40.3 link#1 UHS lo0 show ip route: C>* 10.10.40.0/24 [0/1] is directly connected, vtnet0, 00:18:48 S 10.10.40.0/24 [1/0] via 9.8.6.7, vtnet0, weight 1, 00:19:30 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-06zebra: Convert srcdest_rnode2str to %pRN in zebra_rib.cDonald Sharp
There were a bunch of places where we converted the route node to a prefix string via srcdest_rnode2str when we should have been using %pRN in zebra_rib.c. Just convert over the ones we should to use it. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-06zebra: short-circuit rib_process when nothing to doDonald Sharp
When we are calling rib_process and the route_node in question has no dest, there is no work to do here at all. As such we should just return before attempting to do any other work. This is just a tiny bit of simplification being done. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-07-19zebra: process EVPN remote VTEP updates from the workqueueMark Stapp
Move remote VTEP updates from immediate, inline processing in their ZAPI message handlers to the main workqueue. Signed-off-by: Mark Stapp <mjs@voltanet.io>
2021-07-19zebra: use workqueue for vxlan remote macip updatesMark Stapp
Enqueue incoming vxlan remote macip updates on the main workqueue, instead of performing the updates immediately, in-line. Signed-off-by: Mark Stapp <mjs@voltanet.io>
2021-07-19zebra: add workqueue support for EVPN updatesMark Stapp
Add workqueue subqueue for EVPN/VxLAN updates; migrate the evpn route and remote ES processing from their ZAPI handlers to the workqueue. Signed-off-by: Mark Stapp <mjs@voltanet.io>
2021-07-01*: Replace IPV4_MAX_PREFIXLEN to IPV4_MAX_BITLENDonatas Abraitis
Just drop IPV4_MAX_PREFIXLEN at all, no need keeping both. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-07-01*: Replace IPV6_MAX_PREFIXLEN to IPV6_MAX_BITLENDonatas Abraitis
Just drop IPV6_MAX_PREFIXLEN at all, no need keeping both. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-06-11zebra: use const in rib_matchMark Stapp
Use const in common rib_match api. Signed-off-by: Mark Stapp <mjs@voltanet.io>
2021-05-18Merge pull request #8535 from opensourcerouting/zlog-rnodeDonatas Abraitis
zebra: replace _rnode_zlog with %pZN ext
2021-05-02zebra: replace _rnode_zlog with %pZN extDavid Lamparter
Since _rnode_zlog was wrapping zlog(), these messages weren't getting an unique ID assigned through the xref mechanism. Replace macro with a small extension that prints (almost) the same thing. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2021-04-30zebra: new dplane action to set gre link interfacePhilippe Guibert
This action is initiated by nhrp and has been stubbed when moving to zebra. Now, a netlink request is forged to set the link interface of a gre interface if that gre interface does not have already a link interface. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2021-04-27Merge pull request #8488 from mjstapp/more_workqueueStephen Worley
lib, zebra: use zebra workqueue for NHG updates
2021-04-22zebra: include nexthops' label stacks in debugsMark Stapp
Include nexthops' labels in an important debug early in route processing. Signed-off-by: Mark Stapp <mjs@voltanet.io>
2021-04-15zebra: use workqueue for daemon-owned NHGsMark Stapp
Use the main zebra workqueue for daemon-owned NHGs, in addition to processing kernel-owned NHGs. The zapi message processing creates a temporary object that's enqueued to the workqueue, then processed/installed as part of the workqueue processing. Signed-off-by: Mark Stapp <mjs@voltanet.io>
2021-04-13zebra, lib: replace ZEBRA_ROUTE_NEIGH with simplified versionPhilippe Guibert
do not add a new route type, and consider 0 as a value meaning that zebra should be the owner. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2021-04-09zebra: move neighbor table configuration to dplane contextsPhilippe Guibert
Instead of directly configuring the neighbor table after read from zapi interface, a zebra dplane context is prepared to host the interface and the family where the neighbor table is updated. Also, some other fields are hosted: app_probes, ucast_probes, and mcast_probes. More information on those fields can be found on ip-ntable configuration. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2021-04-09zebra, lib: handle NEIGH_ADD/DELETE to zebra dataplane frameworkPhilippe Guibert
EVPN neighbor operations were already done in the zebra dataplane framework. Now that NHRP is able to use zebra to perform neighbor IP operations (by programming link IP operations), handle this operation under dataplane framework: - assign two new operations NEIGH_IP_INSTALL and NEIGH_IP_DELETE; this is reserved for GRE like interfaces: example: ip neigh add A.B.C.D lladdr E.F.G.H - use 'struct ipaddr' to store and encode the link ip address - reuse dplane_neigh_info, and create an union with mac address - reuse the protocol type and use it for neighbor operations; this permits to store the daemon originating this neighbor operation. a new route type is created: ZEBRA_ROUTE_NEIGH. - the netlink level functions will handle a pointer, and a type; the type indicates the family of the pointer: AF_INET or AF_INET6 if the link type is an ip address, mac address otherwise. - to keep backward compatibility with old queries, as no extension was done, an option NEIGH_NO_EXTENSION has been put in place - also, 2 new state flags are used: NUD_PERMANENT and NUD_FAILED. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2021-03-22zebra: kill zebra_memory.h, use MTYPE_STATICDavid Lamparter
This one also needed a bit of shuffling around, but MTYPE_RE is the only one left used across file boundaries now. Signed-off-by: David Lamparter <equinox@diac24.net>
2021-03-17*: require semicolon after DEFINE_HOOK & co.David Lamparter
See previous commit. Signed-off-by: David Lamparter <equinox@diac24.net>
2021-03-14zebra: move up prefix2str call in rib dumpDavid Lamparter
Signed-off-by: David Lamparter <equinox@diac24.net>
2021-03-10zebra: move ipset and ipset_entry to zebra dplane contextsPhilippe Guibert
like it has been done for iptable contexts, a zebra dplane context is created for each ipset/ipset entry event. The zebra_dplane_ctx job is then enqueued and processed by separate thread. Like it has been done for zebra_pbr_iptable context, the ipset and ipset entry contexts are encapsulated into an union of structures in zebra_dplane_ctx. There is a specificity in that when storing ipset_entry structure, there was a backpointer pointer to the ipset structure that is necessary to get some complementary information before calling the hook. The proposal is to use an ipset_entry_info structure next to the ipset_entry, in the zebra_dplane context. That information is used for ipset_entry processing. The ipset name and the ipset type are the only fields necessary. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2021-03-04zebra: move iptable handling in zebra_dplanePhilippe Guibert
The iptable processing was not handled in remote dataplane, and was directly processed by the thread in charge of zapi calls. Now that call can be handled in the zebra_dplane separate thread. once a zebra_dplane_ctx is allocated for iptable handling, the hook call is performed later. Subsequently, a return code may be triggered to zclient interface if any problem occurs when calling the hook call. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2021-02-14*: remove tabs & newlines from log messagesDavid Lamparter
Neither tabs nor newlines are acceptable in syslog messages. They also break line-based parsing of file logs. Signed-off-by: David Lamparter <equinox@diac24.net>
2021-01-28zebra: Remove #if 0 codeDonald Sharp
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-01-15zebra: Allow rib_update_table to receive a specified route typeDonald Sharp
When we need to cause a reprocessing of data the code currently marks all routes as needing to be looked at. Modify the rib_update_table code to allow us to specify a specific route type we only want to reprocess. At this point none of the code is behaving differently this is just setup for a future code change. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-01-15zebra: remove unused function rib_update_vrfDonald Sharp
The function rib_update_vrf is never used. Remove it. Signed-off-by: Donald Sharp <sharpd@nvidia.com>