summaryrefslogtreecommitdiff
path: root/pimd/pim_nht.h
AgeCommit message (Collapse)Author
2025-01-09pimd: Implement rpf lookup mode as a listNathan Bahr
Add the support to store lookup modes as a sorted list. List is non-unique and sorts mode with both lists < modes with one list < global mode (no lists). This way, when finding the right mode, we will match a lookup using a prefix list before the global mode. Add passing group address into all lookups (using nht cache and/or synchronous lookup). Many areas don't have a group address, use PIMADDR_ANY if no valid group is needed. Signed-off-by: Nathan Bahr <nbahr@atcorp.com>
2025-01-09pimd,yang: Expand rpf-lookup-mode commandNathan Bahr
Add options for group-list and source-list, both of which take a prefix list name. The prefix list is used to determine the lookup mode for specific sources and/or groups. Any number of lookup modes can be configured as long as the combination of group and source list is unique. A global lookup mode (empty group and source lists) is always added and defaults to mrib-then-urib as it currently functions. The global lookup mode can be changed as it current exists with the command `rpf-lookup-mode MODE`. When determinig which mode to use, match source (and group if provided) against the lists, if they are set. If a lookup does not specify a group, then only use lookup modes that do not have a group list defined. A lookup by definition will have a source, so no special handling there. Signed-off-by: Nathan Bahr <nbahr@atcorp.com>
2024-12-13pimd: Update nexthops when lookup mode changesNathan Bahr
Link up the RPF lookup mode changing to a force update to RP's and upstreams registered for nexthop lookup cache updates. Signed-off-by: Nathan Bahr <nbahr@atcorp.com>
2024-12-13pimd: Refactor pim NHTNathan Bahr
Refactor the next hop tracking in PIM to fully support the configured RPF lookup mode. Moved many NHT related functions to pim_nht.h/c NHT now tracks both MRIB and URIB tables and makes nexthop decisions based on the configured lookup mode. Signed-off-by: Nathan Bahr <nbahr@atcorp.com>
2024-10-08*: Allow 16 bit size for nexthopsDonald Sharp
Currently FRR is limiting the nexthop count to a uint8_t not a uint16_t. This leads to issues when the nexthop count is 256 which results in the count to overflow to 0 causing problems in the code. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-06-20pimd: prepare NHT for tracking BSM C-RPsDavid Lamparter
For BSMs, we should track which of the RP candidates in the BSM message are actually available, before trying to use them (which also puts them in NHT for that). This applies for both BSRs as well as BSM receivers. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2023-11-20pimd: use `zclient->nexthop_update`David Lamparter
Same as before, use shared nexthop decode function. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2023-02-09*: auto-convert to SPDX License IDsDavid Lamparter
Done with a combination of regex'ing and banging my head against a wall. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2022-11-14pimd, pim6d: Update upstream rpf disable/enable pim on interfaceSarita Patra
Problem: When "no ip pim" is executed on source connected interface, its ifp->info is set to NULL. But KAT on this interface is still running, it wrongly dereferences NULL. This leads to crash. Root Cause: pim upstream IIF is still pointing towards the source connected interface which is not pim enabled and Mroute is still present in the kernel. Fix: When “no ip pim” command gets executed on source connected interface, then loop through all the pnc->nexthop, if any new nexthop found, then update the upstream IIF accordindly, if not found then update the upstream IIF as Unknown and uninstall the mroute from kernel. When “ip pim” command gets executed on source connected interface, then also loop through all the pnc->nexthop and update the upstream IIF, install the mroute in kernel. Issue: #10782 Issue: #11931 Signed-off-by: Sarita Patra <saritap@vmware.com>
2022-11-14pimd, pim6d: Introduce pnc_hash_walk_data structureSarita Patra
This structure will contain pim_instance and interface data. Signed-off-by: Sarita Patra <saritap@vmware.com>
2022-07-07pim6d: bsr nht handling for IPV6sarita patra
Signed-off-by: sarita patra <saritap@vmware.com>
2022-07-06pim6d: Pass pim_addr for pim_nht callbacks.sarita patra
For pim callbacks, we pass pim_addr as value, not pointer. So making it consistent for pim_nht callbacks. Signed-off-by: sarita patra <saritap@vmware.com>
2022-07-06pimd: Handle rpf_addr in pim nhtsarita patra
Signed-off-by: sarita patra <saritap@vmware.com>
2022-03-25pim6d: Parse BSM packet for PIMv6Mobashshera Rasool
Modify pim_bsm_process to accomodate v4 and v6 address for parsing the received packet. Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
2021-11-17pimd: add back blocking RPF for BSMDavid Lamparter
NHT won't have a result yet when we get the first BSM from a new BSR. Hence, the first packet(s) are lost, since their RPF validation fails. Re-add the blocking RPF check that was there before (though in a much more sensible manner.) Also nuke the now-unused pim_nexthop_match* functions. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2021-11-17pimd: clean up BSR NHT & fix parallel linksDavid Lamparter
The Bootstrap message RX path needs a RPF check for the BSR address, and this is implemented both incorrectly as well as quite ugly. Clean up and fix case when we have multiple interfaces to the same LAN and/or ECMP nexthops (both would cause message duplication, the former can even cause BSM forwarding loops.) Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2019-05-28Merge pull request #4239 from sarav511/rpJafar Al-Gharaibeh
pimd: PIM Bootstrap Message Processing
2019-05-14pimd: Implement nexthop match where if given address match any of the next ↵saravanank
hop in ecmp case For each BSM packet, rpf check is performed. We will be accepting if the source address match any of the next hop neighbor(in ecmp case) to reach the Bootstrap Router. 1. pim_nexthop_match - this lookup in zebra and return true if any of the next hop nbr is matching (in ecmp case). 2. pim_nexthop_match_nht_cache - this api searches the given address in local pnc and return true if any of the next hop nbr is matching (in ecmp case). Signed-off-by: Saravanan K <saravanank@vmware.com>
2019-05-14pimd: PIM nexthop tracking changes for tracking nexthop path of BSR.saravanank
Signed-off-by: Saravanan K <saravanank@vmware.com>
2019-05-03*: use ZAPI_CALLBACK_ARGS macro for zapi handlersQuentin Young
This macro: - Marks ZAPI callbacks for readability - Standardizes argument names - Makes it simple to add ZAPI arguments in the future - Ensures proper types - Looks better - Shortens function declarations Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2019-04-05pimd: Add a flag PIM_NEXTHOP_ANSWER_RECEIVEDDonald Sharp
Track whether or not we have received an answer from our query to do nexthop tracking. This allows us to go straight to doing a synchronous query for our RPF. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2019-04-05pimd: Tracking of RPF is *separate* from the lookupDonald Sharp
Start the separation of tracking a Destination from the act of looking it up. The cojoining of these two concepts led to a bunch of code that had to think about both problems leading to weird situations and code paths. Simplify the code by making pim_ecmp_nexthop_search a static function and we only ever call pim_ecmp_nexthop_lookup when we need to do a RPF(). pim_ecmp_nexthop_lookup will now attempt to find a stored pnc and if it finds one it will report on the answer from it. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2019-04-02pimd: Remove pim_resolve_upstream_nhDonald Sharp
The pim_resolve_upstream_nh function call is no longer being used let's remove it from the code base. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2019-02-24pimd: clear rp_info source_nexthop when RP becomes not reachableSarita Patra
When route to RP gets modified, FRR receives a notification from zebra, and call the function pim_update_rp_nh() to compute the new nexthop and will update the source_nexthop information of rp_info. This is not working for the case when RP becomes not reachable. Fix: When FRR receives a notification from zebra saying RP becomes not reachable, then delete the source_nexthop informatio of rp_info. Signed-off-by: Sarita Patra <saritap@vmware.com>
2018-07-07pimd: Remove duplicate parameter to functionsDonald Sharp
Both pim_ecmp_nexthop_lookup and pim_ecmp_fib_lookup_if_vif_index pass the address in 2 times. Make function calls consistent and just pass in the src once. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2018-03-27*: use C99 standard fixed-width integer typesQuentin Young
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>
2017-07-25pimd: NHT upstream list is inefficientDonald Sharp
The NHT upstream list at scale is horribly inefficient due to keeping a sorted list of upstream entries. The attempting to find the upstream and the insertion of it into the upstream_list was consuming a large amount of cpu cycles. Convert to a hash, allow add/deletions to effectively become O(1) events. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2017-07-24pimd: Fixup NHT debugging to be a bit more coherentDonald Sharp
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2017-07-24pimd: Put 'struct pim_instance *' as the first function parameterDonald Sharp
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2017-07-24pimd: Remove pimg from pim_nht.c in totalityDonald Sharp
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2017-07-24pimd: More refactor for 'struct pim_instance *' for pim_nht.cDonald Sharp
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2017-07-24pimd: Add 'struct pim_instance' to find_or_track_nexthopDonald Sharp
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2017-07-24pimd: Make nexthop cache pim instance awareDonald Sharp
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2017-07-17*: reindentreindent-master-afterwhitespace / reindent
indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-05-15*: make consistent & update GPLv2 file headersDavid Lamparter
The FSF's address changed, and we had a mixture of comment styles for the GPL file header. (The style with * at the beginning won out with 580 to 141 in existing files.) Note: I've intentionally left intact other "variations" of the copyright header, e.g. whether it says "Zebra", "Quagga", "FRR", or nothing. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-05-06pimd: fix channel_oil and upstream RPF in syncChirag Shah
During PIM Neighbor change/UP event, pim_scan_oil api scans all channel oil to see any rpf impacted. Instead of passing current upstream's RPF it passes current RPF as 0 and does query to rib for nexhtop (without ECMP/Rebalance). This creates inconsist RPF between Upstream and Channel oil. In Channel Oil keep backward pointer to upstream DB and fetch up's RPF and passed to channel_oil scan. Decrement channel_oil ref_count in upstream_del when decrementing up ref_count and it is not the last. Created ECMP based FIB lookup API. Testing Done: Performed following testing on tester setup: 5 x LHR, 4 x MSDP Spines, 6 Sources each sending to 1023 groups from one of the spines. Total send rate 8Mpps. Test that caused problems was to reboot every device at the same time. After fix performed 5 iterations of reboot devices and show no sign of the problem. Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
2017-04-25pimd: Pim Nexthop Tracking support with ECMPChirag Shah
In this patch, PIM nexthop tracking uses locally populated nexthop cached list to determine ECMP based nexthop (w/ ECMP knob enabled), otherwise picks the first nexthop as RPF. Introduced '[no] ip pim ecmp' command to enable/disable PIM ECMP knob. By default, PIM ECMP is disabled. Intorudced '[no] ip pim ecmp rebalance' command to provide existing mcache entry to switch new path based on hash chosen path. Introduced, show command to display pim registered addresses and respective nexthops. Introuduce, show command to find nexthop and out interface for (S,G) or (RP,G). Re-Register an address with nexthop when Interface UP event received, to ensure the PIM nexthop cache is updated (being PIM enabled). During PIM neighbor UP, traverse all RPs and Upstreams nexthop and determine, if any of nexthop's IPv4 address changes/resolves due to neigbor UP event. Testing Done: Run various LHR, RP and FHR related cases to resolve RPF using nexthop cache with ECMP knob disabled, performed interface/PIM neighbor flap events. Executed pim-smoke with knob disabled. Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com> (cherry picked from commit cba444817883b8b3b22a7ed9958dc9ed77f76230)
2017-03-31pimd: Cleanup api and stop crashDonald Sharp
There is no need for a function that calls another function. Additionally, nexthop_updates from zebra can be either ZEBRA_NEXTHOP_UPDATE -or- ZEBRA_IMPORT_CHECK_UPDATE If we were to receive a IMPORT_CHECK_UPDATE the code would cause a immediate crash. Fix this Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2017-03-16pimd: Nexthop tracking supportChirag Shah
Add pim Nexthop tracking feature 1st part where, specific RP or Source address (unicast address) register with Zebra. Once nexthop update received from Zebra for a given address, scan RP or upstream entries impacted by the change in nexthop. Reviewed By: CCR-5761, Donald Sharp <sharpd@cumulusnetworks.com> Testing Done: Tested with multiple RPs and multiple *,G entries at LHR. Add new Nexthop or remove one of the link towards RP and verify RP and upstream nexthop update. similar test done at RP with multiple S,G entries to reach source. Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>