summaryrefslogtreecommitdiffstats
path: root/pimd/pim_oil.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* pimd: Fix (S,G) debug issueSarita Patra2022-12-161-2/+2
| | | | Signed-off-by: Sarita Patra <saritap@vmware.com>
* pimd: Fix the setting of oif_flags in channel oilMobashshera Rasool2022-06-151-0/+2
| | | | | | | | | | | | | | | | | | When pim_upstream_inherited_olist_decide calls the api pim_channel_add_oif, it can pass PIM_OIF_FLAG_PROTO_GM, PIM_OIF_FLAG_PROTO_PIM and/or PIM_OIF_FLAG_PROTO_STAR. Now a consider a case where PIM flag was already set but STAR flag was not set and this api tries to set both STAR + PIM and passes the same. The api pim_channel_add_oif returns since it sees that PIM is already set without setting the STAR flag. So basically this will lead to issues in scenarios where for the same OIF multiple flags(IGMP, PIM, STAR) needs to be set. Fixing it for all combinations. Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
* pimd: Fixup oil_if_has and oil_if_set to be consistentDonald Sharp2022-06-091-1/+1
| | | | | | the v4 and v6 versions were different. Make them the same. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* pimd: Fix pim_channel_oil_empty testsDonald Sharp2022-06-091-14/+6
| | | | | | | | | | | | | | The pim_channel_oil_empty() function was setting the pimreg if it ever existed for NULL comparison but of course the pimreg device is never pulled back out again when it was needed to be when the pimreg is not present. Commit: a5fa982256b23d53d5b833f75224fb7f96054b9b broke this. Fixes: #11368 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* pim6d: Mroute changesplsaranya2022-03-231-6/+13
| | | | | | Mroute and supporting changes Signed-off-by: plsaranya <Saranya_Panjarathina@dell.com>
* pimd: add safety check to OIL add/delDavid Lamparter2022-03-121-0/+8
| | | | | | | | These will corrupt memory if mroute_vif_index is -1 (e.g. interface not operating.) That shouldn't happen, but it does while doing development work, so trip an assert rather than corrupting memory. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* pim6d: IPv6-adjust mroute codeDavid Lamparter2022-02-161-148/+78
| | | | | | | | This is just hitting the pim_mroute code with a hammer until it doesn't print warnings anymore. This is NOT quite tested or working yet, it just compiles. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* pimd: move, rename and deploy pim_addr_is_any()David Lamparter2022-01-171-2/+2
| | | | | | | | | Replaces comparison against INADDR_ANY, so we can do IPv6 too. (Renamed from "pim_is_addr_any" for "pim_addr_*" naming pattern, and type fixed to bool.) Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* pimd: remove pim_str_sg_dump()David Lamparter2022-01-171-4/+3
| | | | | | | | ... and replace with `%pSG` printfrr specifier. This actually used a static buffer in the formatting function, so subsequent formatting would overwrite earlier uses. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* pimd: `prefix_sg` => `pim_sgaddr`David Lamparter2022-01-121-8/+7
| | | | | | | | | | | Mostly just 2 sed calls: - `sed -e 's%struct prefix_sg%pim_sgaddr%g'` - `sed -e 's%memset(&sg, 0, sizeof(pim_sgaddr));%memset(\&sg, 0, sizeof(sg));%g'` Plus a bunch of fixing whatever that broke. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* pimd: move `%pSG4` to `%pPSG4`David Lamparter2022-01-121-2/+2
| | | | | | | Since this is only used in very few places, moving it out of the way is reasonable. (`%pSG` will be pim_sgaddr) Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* pimd: Cleanup weird indentationDonald Sharp2022-01-081-17/+15
| | | | | | | | The zlog_warn used to be bounded by a debug guard but the debug guard was removed but the code was never fixed up to remove the open and close paranthesis. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* pimd: Fix rare crash situationDonald Sharp2021-05-191-3/+5
| | | | | | | | | | When running pim on an interface and that interface has state and we move that interface into a different vrf there exists a call path where we have not created the pimreg device yet. Prevent a crash in this rare situation. Ticket: #2552763 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* pimd: zassert => assertDavid Lamparter2021-04-231-2/+2
| | | | | | | No point in having pimd use zassert() while everything else uses plain assert(). Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* pimd: Fix missing codeDonald Sharp2020-06-031-0/+14
| | | | | | | | Found some more missing code that got dropped during the upstreaming process causing issues with things actually working. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* pimd: logs to help debug leaked channel OIF problemsAnuradha Karuppiah2020-03-061-0/+17
| | | | | | | | | | | | | Additional protocols were being set on the OIF proto-mask without logs. Added logs in that area. Also added start and end logs to ifchannel_delete to help identify state machine changes that play out as a part of this event handling. Ticket: CM-26732 Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
* pimd: Add accidently missed code during upstreaming processDonald Sharp2020-03-061-4/+1
| | | | | | | | | | There was some code missed during the upstreaming process due to code squash. Identify and put into a commit to keep code consistent and correct. Signed-off-by: Satheesh Kumar K <sathk@cumulusnetworks.com> Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com> Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* *: Replace __PRETTY_FUNCTION__/__FUNCTION__ to __func__Donatas Abraitis2020-03-051-23/+21
| | | | | | Just keep the code cool. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
* pimd: Convert the upstream_list and hash to a rb treeDonald Sharp2020-01-031-20/+0
| | | | | | | | Convert the upstream_list and hash to a rb tree, Significant time was being spent in the listnode_add_sort. This reduces this time greatly. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* pimd: Convert the channel_oil_list|hash to a rb_treeDonald Sharp2020-01-031-22/+11
| | | | | | | | The channel_oil_list and hash are taking significant cpu at scale when adding to the sorted list. Replace with a RB_TREE. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* pimd: exclude pimreg from the inherited OILAnuradha Karuppiah2019-11-191-2/+6
| | | | | | | | | | | | | | Inherited OIL is used as a part of the JoinDesired macro. And in FRR we use the channel OIL as the inherited OIL (to reduce processing overhead everytime JD needs to be re-evaluated). On a FHR pimreg is a part of the channel-OIL but must not be used for JD computation. This commit blacklists pimreg from the inherited_oil i.e. present but ignored. Note: This fixup is being done to address topotest failures. Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
* pimd: enforce PIM_ENFORCE_LOOPFREE_MFC at the time of MFC programmingAnuradha Karuppiah2019-11-151-43/+0
| | | | | | | | | | This is needed for two reasons - 1. The inherited OIL needs to be setup independent of the RPF interface to allow correct computation of the JoinDesired macro. 2. The RPF interface is computed at the time of MFC programming so it is not possible to permanently evict the OIF at that time oif_add Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
* pimd: re-eval JD on sources when a STAR_OIF is removedAnuradha Karuppiah2019-11-151-0/+15
| | | | | | | When a inherited OIL becomes empty join-desired can go to false. So we need to re-run join-desired evaluation on any inherited OIL changes. Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
* pimd: fixup pim_channel_oil_empty macroAnuradha Karuppiah2019-11-151-11/+3
| | | | | | | The macro was always returning non-empty because of comparing an array of u8_t with an array of u32_t. Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
* pimd: set mfcc_parent at the time of MFCC programmingAnuradha Karuppiah2019-11-151-64/+10
| | | | | | | | | | mfcc_parent for an (S, G) entry was being updated on any upstream RPF change. With the change to use RPT for (S,G) in some cases we can no longer do that. Instead the upstream entry's RPF neigbor is managed separately form the channel_oil's mfcc_parent i.e. via NHT. And the mfcc_parent is evaluated at the time of mroute programming. Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
* pimd: decide between SPT based and RPT based forwardingAnuradha Karuppiah2019-11-151-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An (S,G) mroute can be created as a result of rpt prune. However that entry needs to stay on the parent (*,G)'s tree (IIF) till a decision is made to switch the source to the SPT. The decision to stay on the RPT is made based on the SPTbit setting according to - RFC7761, Section 4.2 “Data Packet Forwarding Rules” However those rules are hard to achieve when hw acceleration i.e. control and data planes are separate. So instead of relying on data we make the decision of using SPT if we have decided to join the SPT - Use_RPT(S,G) { if (Joined(S,G) == TRUE // we have decided to join the SPT OR Directly_Connected(S) == TRUE // source is directly connected OR I_am_RP(G) == TRUE) // RP //use_spt return FALSE; //use_rpt return TRUE; } To make that change some re-org was needed - 1. pim static mroutes and dynamic (upstream mroutes) top level APIs have been separated. This is to limit the state machine to dynamic mroutes. 2. c_oil->oil.mfcc_parent is re-evaluated based on if we decided to use the SPT or stay on the RPT. 3. upstream mroute re-eval is done when any of the criteria involved in Use_RPT changes. Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
* pimd: re-eval c_oil mute flags on upstream attach/detachAnuradha Karuppiah2019-11-151-3/+49
| | | | | | | | | Theoretically there should be no case where the channel-oil hangs around after the upstream entry is removed. But currently there are cases where it does. This is a precautionary fixup till we are rid off all of those cases. Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
* pimd: MUTE flag to suppress traffic forwarding on non-DFAnuradha Karuppiah2019-11-151-2/+89
| | | | | | | | | | | | | | | | | | | | | | | | | If an mroute loses DF election (with the MLAG peer) it has to stop forwarding traffic on active-active devices such as ipmr-lo used for vxlan traffic termination. To acheive that this commit introduces a concept of OIF muting. That way we can let the PIM and IGMP state machines play out and silence OIFs after the fact. Relevant outputs: ================= 1. muted OIFs are displayed with the M flag in "pim state" - >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> root@TORC12:~# net show pim state |grep "27.0.0.13"|grep 100 1 27.0.0.13 239.1.1.100 uplink-1 ipmr-lo( *M) root@TORC12:~# >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2. And supressed altogether in the mroute output - >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> root@TORC12:~# net show mroute |grep "27.0.0.13"|grep 100 27.0.0.13 239.1.1.100 none uplink-1 none 0 --:--:-- root@TORC12:~# >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
* pimd: update add_oif and del_oif debugs to print callerAnuradha Karuppiah2019-11-151-6/+6
| | | | | | | | | | | These logs were printing file name which has little value (is always pim_oil.c). Instead print the caller. add_oif/del_oif are being called directly from one too many. Instead OIF setup needs to be consolidated via the PIM state machine. These debugs are expected to help in understanding what needs to be cleaned up. Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
* pimd: Add pim_channel_oil_change_iifDonald Sharp2019-07-181-1/+39
| | | | | | | Add a function that allows you to modify the channel oil's incoming interface and to appropriately install/remove it from the kernel. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* Merge pull request #4518 from sarav511/dr_lhrDonald Sharp2019-06-221-3/+5
|\ | | | | pimd: fix DR at LHR scenario where non DR is connected to RP
| * pimd: fix DR at LHR scenario where non DR is connected to RPsaravanank2019-06-131-3/+5
| | | | | | | | | | | | | | | | | | In Scenario where receiver is present in a subnet where 2 or more pim mrouters. When IGMP query received on a DR interface and RP is reachable through non DR. Currently we are blocking to create upstream where iif == oif. So pim join not generated towards RP. We have to allow the DR router in the network to create an upstream. Signed-off-by: Saravanan K <saravanank@vmware.com>
* | pimd: Add debugs for channel_oil creation and deletionDonald Sharp2019-06-151-11/+27
| | | | | | | | | | | | | | Add some debugs so we can see channel oil creation and deletion events. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* | pimd: Display ifp name in pim_channel_oil_dumpDonald Sharp2019-06-151-3/+7
|/ | | | | | | The vifi being displayed is just confusing. Display the actual interface name being used in the mroute. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* lib: hashing functions should take const argumentsQuentin Young2019-05-141-2/+2
| | | | | | | | | | It doesn't make much sense for a hash function to modify its argument, so const the hash input. BGP does it in a couple places, those cast away the const. Not great but not any worse than it was. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
* pimd: allow mroutes with IIF in the OILAnuradha Karuppiah2019-04-201-1/+9
| | | | | | | | | | | | | | This is specifically needed to allow pim-evpn mroutes in the MLAG setup - (36.0.0.11, 239.1.1.100) Iif: peerlink.4094 Oifs: uplink-1, peerlink.4094 I could have gone the other way and disabled PIM_ENFORCE_LOOPFREE_MFC but that opens the door too wide. Relaxing the checks for mlag-specific mroutes seemed like the safer choice. This commit provides the infrastructure to relax checks on a per-mroute basis. Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
* pimd: Addressing the review commentsSarita Patra2019-03-191-7/+3
| | | | Signed-off-by: Sarita Patra <saritap@vmware.com>
* pimd: Don't install dummy channel oil entry into KernelSarita Patra2019-02-251-18/+24
| | | | | | | If the channel oil is dummy(channel_oil->is_valid != True), then don't install entry into the kernel. Signed-off-by: Sarita Patra <saritap@vmware.com>
* pimd: create dummy (*,G) upstream when RP not configured/reachableSarita Patra2019-02-251-7/+13
| | | | | | | | | In this commit, we are creating a dummy upstream & dummy channel_oil for (*, G) when RP is not configured or not reachable. Dummy upstream: <upstream_addr = INADDR_ANY, rpf = Unknown> Dummy channel oil: <iif = MAXVIFS> Signed-off-by: Sarita Patra <saritap@vmware.com>
* pimd: Don't refersh the oif_creation timer if S,G already presentSarita Patra2019-02-081-2/+4
| | | | | | | | | | | | | | | | Issue: Shut the RP interface in the router RP. LHR will get to know RP becomes not-reachable, so it send a prune towards the RP. On receiving the prune, RP clear the (*, G) entry, but (S, G) should not get removed if present. Now no-shut the RP interface in the router RP. LHR will send a (*, G) join towards the RP. On receiving join FRR create the (*, G) entry. Along with this, it also add the interface(join received) in the OIL of (S, G) and also refresh the (S, G) timer. Fix: Dont refresh the timer for S, G or (*, G), if the flag for the channel OIL is PIM_OIF_FLAG_PROTO_ANY. Signed-off-by: Sarita Patra <saritap@vmware.com>
* *: Replace hash_cmp function return value to a boolDonald Sharp2018-10-191-3/+3
| | | | | | | | | The ->hash_cmp and linked list ->cmp functions were sometimes being used interchangeably and this really is not a good thing. So let's modify the hash_cmp function pointer to return a boolean and convert everything to use the new syntax. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* *: list_delete_and_null() -> list_delete()David Lamparter2018-10-021-1/+1
| | | | Signed-off-by: David Lamparter <equinox@diac24.net>
* *: fix gcc-8 format-overflow warningsDavid Lamparter2018-08-211-5/+6
| | | | | | | | | | e.g. pimd/pim_oil.c: In function ‘pim_channel_oil_dump’: pimd/pim_oil.c:51:19: error: ‘%d’ directive writing between 1 and 11 bytes into a region of size 10 [-Werror=format-overflow=] Build on gcc-8.2.0 is warning-free after this patch. Signed-off-by: David Lamparter <equinox@diac24.net>
* pimd: Remove unnecessary alloc failuresDonald Sharp2018-07-081-9/+0
| | | | | | | Remove from pim unnecessary alloc failure testing as that alloc failure will cause an assert. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* ospfd, pimd: redundant memset (cppcheck)paco2018-06-181-1/+0
| | | | Signed-off-by: F. Aragon <paco@voltanet.io>
* *: conform with COMMUNITY.md formatting rules, via 'make indent'Lou Berger2018-03-061-4/+2
| | | | Signed-off-by: Lou Berger <lberger@labn.net>
* pimd: Multicast traceroute client and routerMladen Sablic2018-02-191-2/+2
| | | | | | | | This commit is the implementation of weak multicast traceroute. It consists of IGMP module dealing with mtrace type IGMP messages and client program mtrace/mtracebis for initiating mtrace queries. Signed-off-by: Mladen Sablic <mladen.sablic@gmail.com>
* *: Convert list_delete(struct list *) to ** to allow nullingDonald Sharp2017-10-051-2/+1
| | | | | | | | | | | | | | | | | | | Convert the list_delete(struct list *) function to use struct list **. This is to allow the list pointer to be nulled. I keep running into uses of this list_delete function where we forget to set the returned pointer to NULL and attempt to use it and then experience a crash, usually after the developer has long since left the building. Let's make the api explicit in it setting the list pointer to null. Cynical Prediction: This code will expose a attempt to use the NULL'ed list pointer in some obscure bit of code. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* pimd: Squash some more memory leaksDonald Sharp2017-08-021-1/+1
| | | | | | | | | | | When a interface is flapped we were leaking some memory associated with link lists. Especially in the jp_agg code. If your network was/is stable and you are not running at any scale you probably would not see this as impactful at all. Ticket: CM-16392 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* pimd: Setup hash names appropriatelyDonald Sharp2017-07-251-2/+7
| | | | Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-02 10:19:21 +0100