summaryrefslogtreecommitdiffstats
path: root/pimd/pim_zebra.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* pimd: replace inet_ntoaMark Stapp2020-10-221-4/+4
| | | | | | Replace all use of inet_ntoa, using %pI4 or inet_ntoa instead Signed-off-by: Mark Stapp <mjs@voltanet.io>
* :* Convert prefix2str to %pFXDonatas Abraitis2020-10-221-18/+7
| | | | Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
* pimd: Allow mlag to create ifchannelDonald Sharp2020-06-031-1/+1
| | | | | | | | | | | When the mlag code was ported upstream the structure of the calls in igmp_source_forward_start had been reset and as a result we missed the call to check that creating an ifchannel when we are DualActive is allowed. Ticket: CM-29941 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* pimd: fix OIL not removed after IGMP pruneSarita Patra2020-03-171-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Issue: Client1------LHR-----(int-1)RP(int-2)------client2 Client2 send IGMP join for group G. Client1 send IGMP join for group G. verify show ip mroute in RP, will have 2 OIL. Client2 send IGMP leave. Verify show ip mroute in RP, will still have 2. Root cause: When RP receives IGMP join from client2, it creates a (s,g) channel oil and add the interface int-2 into oil list and set the flag PIM_OIF_FLAG_PROTO_IGMP to int-2 Client1 send IGMP join, LHR will send a (*,G) join to RP. RP will add the interface int-1 into the oil list of (s,g) channel_oil and will set the flag PIM_OIF_FLAG_PROTO_IGMP and PIM_OIF_FLAG_PROTO_PIM to the int-1 and set PIM_OIF_FLAG_PROTO_PIM to int-2 as well. It is happening because of the pim_upstream_inherited_olist_decide() and forward_on() get all the oil and update the flag wrongly. So now when client 2 sends IGMP prune, RP will not remove the int-2 from oil list since both PIM_OIF_FLAG_PROTO_PIM & PIM_OIF_FLAG_PROTO_IGMP are set, it just unset the flag PIM_OIF_FLAG_PROTO_IGMP. Fix: Introduced new flags in if_channel, PIM_IF_FLAG_MASK_PROTO_PIM & PIM_IF_FLAG_MASK_PROTO_IGMP. If a if_channel is created because of pim join or pim (s,g,rpt) prune received, then set the flag PIM_IF_FLAG_MASK_PROTO_PIM. If a if_channel is created becuase of IGMP join received, then set the flag PIM_IF_FLAG_MASK_PROTO_IGMP. When an interface needs to be added into the oil list check if PIM_IF_FLAG_MASK_PROTO_PIM or PIM_IF_FLAG_MASK_PROTO_IGMP is set, then update oil flag accordingly. Signed-off-by: Sarita Patra <saritap@vmware.com>
* *: Finish off the __PRETTY_FUNCTION__ to __func__Donald Sharp2020-03-061-4/+3
| | | | | | FINISH IT Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* *: Replace __PRETTY_FUNCTION__/__FUNCTION__ to __func__Donatas Abraitis2020-03-051-60/+48
| | | | | | Just keep the code cool. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
* pimd: stop overloading SRC_IGMP upstream for vxlan local membershipAnuradha Karuppiah2020-02-141-2/+4
| | | | | | | | | | | | | | | | | | A local membership is created on the vxlan termination device ipmr-lo. This is done to - 1. Pull multicast vxlan tunnel traffic to the VTEP for termination by triggering JoinDesired on the BUM multicast group. 2. Include the OIF in the mroute to signal to the dataplane component that flow needs to be vxlan terminated. Earlier we were overloading the PIM_UPSTREAM_FLAG_MASK_SRC_IGMP for this local membership creation but that is creating confusion both in the state machine and in the show outputs. To avoid that we use the more apparent PIM_UPSTREAM_FLAG_MASK_SRC_VXLAN_TERM. With this change - 1. We get LHR functionality for VXLAN_TERM mroutes 2. OIF is populated with PIM_OIF_FLAG_PROTO_PIM only Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
* pim: DF election for tunnel termination mroutes in an anycast-VTEP setupAnuradha Karuppiah2020-02-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | 1. Upstream entries associated with tunnel termination mroutes are synced to the MLAG peer via the local MLAG daemon. 2. These entries are installed in the peer switch (via an upstream ref flag). 3. DF (Designated Forwarder) election is run per-upstream entry by both the MLAG switches - a. The switch with the lowest RPF cost is the DF winner b. If both switches have the same RPF cost the MLAG role is used as a tie breaker with the MLAG primary becoming the DF winner. 4. The DF winner terminates the multicast traffic by adding the tunnel termination device to the OIL. The non-DF suppresses the termination device from the OIL. Note: Before the PIM-MLAG interface was available hidden config was used to test the EVPN-PIM functionality with MLAG. I have removed the code to persist that config to avoid confusion. The hidden commands are still available. Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
* pimd: Convert the channel_oil_list|hash to a rb_treeDonald Sharp2020-01-031-4/+1
| | | | | | | | 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>
* Merge pull request #5355 from AnuradhaKaruppiah/pim-state-machine-fixesJafar Al-Gharaibeh2019-12-071-134/+20
|\ | | | | PIM state machine fixes
| * pimd: jp-agg list update debug logsAnuradha Karuppiah2019-11-151-1/+1
| | | | | | | | | | | | | | | | | | Added event logs around add/del of upstream entries into the nbr's jp-agg list. This is to help debug a problem with stale (deleted) upstream entries being present in the list causing pimd to crash on the periodic processing. Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
| * pimd: handle RPF resolution while in joined stateAnuradha Karuppiah2019-11-151-0/+3
| | | | | | | | | | | | | | | | If an dummy upstream entry (no RPF nbr) which is already in a JOINED state is resolved we were not triggering an immediate join via the per-interface upstream switch list. Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
| * pimd: set mfcc_parent at the time of MFCC programmingAnuradha Karuppiah2019-11-151-124/+4
| | | | | | | | | | | | | | | | | | | | 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/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: update add_oif and del_oif debugs to print callerAnuradha Karuppiah2019-11-151-6/+8
| | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge pull request #5328 from satheeshkarra/pim_mlagMark Stapp2019-11-221-1/+5
|\ \ | |/ |/| pimd, lib, zebra : PIM MLAG Support
| * pimd, lib: adding support for MLAG Message processing at PIMSatheesh Kumar K2019-11-141-0/+4
| | | | | | | | | | | | | | | | | | This includes: 1. Defining message formats 2. Stream Decoding after receiving the message at PIM 3. Handling MLAG UP & Down Notifications Signed-off-by: Satheesh Kumar K <sathk@cumulusnetworks.com>
| * pimd : Add support for MLAG Register & Un-registerSatheesh Kumar K2019-11-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | when ever a FRR Client wants to send any data to another node using MLAG Channel, uses below mechanisam. 1. sends a MLAG Registration to zebra with interested messages that it is intended to receive from peer. 2. In response to this request, Zebra opens communication channel with MLAG. and also in Rx. diretion zebra forwards only those messages which client shown interest during registration 3. when client is no-longer interested in communicating with MLAG, client posts De-register to Zebra 4. if this is the last client which is interested for MLAG Communication, zebra closes the channel. why PIM Needs MLAG Communication ================================ 1. In general on LAN Networks elecetd DR will send the Join towards Multicast RP in case of a LHR and Register in case of FHR. 2. But in case DR Goes down, traffic will be re-converged only after the New DR is elected, but this can take time based on Hold Timer to detect the DR down. 3. this can be optimised by using MLAG Mecganisam. 4. and also Traffic can be forwarded more efficiently by knowing the cost towards RP using MLAG Signed-off-by: Satheesh Kumar K <sathk@cumulusnetworks.com>
* | Merge pull request #5276 from donaldsharp/pim_doubleJafar Al-Gharaibeh2019-11-141-14/+11
|\ \ | |/ |/| pimd: No need to add then remove the oif if not DR
| * pimd: No need to add then remove the oif if not DRDonald Sharp2019-11-041-14/+11
| | | | | | | | | | | | | | When adding an OIF to the OIL, if we are not the DR there is no need to install it then remove it. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* | *: Convert connected_free to a double pointerDonald Sharp2019-11-021-1/+1
|/ | | | | | Set the connected pointer to set the pointer to NULL. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* Revert "Merge pull request #4885 from satheeshkarra/pim_mlag"Quentin Young2019-10-141-5/+1
| | | | | This reverts commit d563896dada99f3474d428f928786cbfde936fee, reversing changes made to 09ea1a40386f02a13cdb0462cc55af0d03f0c277.
* Merge pull request #4885 from satheeshkarra/pim_mlagJafar Al-Gharaibeh2019-10-141-1/+5
|\ | | | | pimd, lib, Zebra: PIM MLAG Support
| * pimd, lib: adding support for MLAG Message processing at PIMSatheesh Kumar K2019-09-241-0/+4
| | | | | | | | | | | | | | | | | | This includes: 1. Defining message formats 2. Stream Decoding after receiving the message at PIM 3. Handling MLAG UP & Down Notifications Signed-off-by: Satheesh Kumar K <sathk@cumulusnetworks.com>
| * pimd : Add support for MLAG Register & Un-registerSatheesh Kumar K2019-09-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | when ever a FRR Client wants to send any data to another node using MLAG Channel, uses below mechanisam. 1. sends a MLAG Registration to zebra with interested messages that it is intended to receive from peer. 2. In response to this request, Zebra opens communication channel with MLAG. and also in Rx. diretion zebra forwards only those messages which client shown interest during registration 3. when client is no-longer interested in communicating with MLAG, client posts De-register to Zebra 4. if this is the last client which is interested for MLAG Communication, zebra closes the channel. why PIM Needs MLAG Communication ================================ 1. In general on LAN Networks elecetd DR will send the Join towards Multicast RP in case of a LHR and Register in case of FHR. 2. But in case DR Goes down, traffic will be re-converged only after the New DR is elected, but this can take time based on Hold Timer to detect the DR down. 3. this can be optimised by using MLAG Mecganisam. 4. and also Traffic can be forwarded more efficiently by knowing the cost towards RP using MLAG Signed-off-by: Satheesh Kumar K <sathk@cumulusnetworks.com>
* | Merge pull request #5009 from donaldsharp/interface_deletionRuss White2019-09-301-216/+6
|\ \ | | | | | | lib, zebra: Allow for interface deletion when kernel event happens
| * | *: Convert zapi->interface_delete to ifp callbackDonald Sharp2019-09-191-30/+0
| | | | | | | | | | | | | | | | | | | | | Convert the callback of the interface_delete to the new ifp callback. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
| * | *: Convert interface_down to interface down callbackDonald Sharp2019-09-191-45/+0
| | | | | | | | | | | | Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
| * | *: Convert from ->interface_up to the interface callbackDonald Sharp2019-09-191-69/+6
| | | | | | | | | | | | | | | | | | | | | For all the places we have a zclient->interface_up convert them to use the interface ifp_up callback instead. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
| * | *: Switch all zclient->interface_add to interface create callbackDonald Sharp2019-09-191-72/+0
| |/ | | | | | | | | | | | | Switch the zclient->interface_add functionality to have everyone use the interface create callback in lib/if.c Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* / pimd: up->channel_oil cannot be NULLDonald Sharp2019-09-251-55/+0
|/ | | | | | | | When we create the up data structure we create the channel_oil as well. As such it is impossible to get into this code so it can be removed. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* pimd: pim_upstream *always* creates a channel_oilDonald Sharp2019-07-181-9/+6
| | | | | | | Modify code base so that pim_upstream *always* creates a channel_oil and as such we do not need to create it later or play other games. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* pimd: Add pim_channel_oil_change_iifDonald Sharp2019-07-181-28/+3
| | | | | | | 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>
* pimd, zebra: request for replay of SG entries on startupAnuradha Karuppiah2019-07-031-0/+20
| | | | | | | | | | | | | zvni setup in zebra is controlled via bgpd i.e. advertise_all_vni from bgpd triggers this setup. As a part of zvni creation we may need to setup BUM mcast SG entries which are propagated to pimd for MDT setup. Now pimd may not be present at the time of zvni creation or may restart post zvni creation so we need a mechanism to replay (on pimd startup) and to cleanup (on pimd stop). This is addressed via zebra_vxlan_sg_replay and zebra_evpn_pim_cfg_clean_up. Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
* Merge pull request #4525 from donaldsharp/some_cleanupsRafael Zalamena2019-06-251-28/+1
|\ | | | | Some cleanups
| * pimd: ALLOC functions cannot fail.Donald Sharp2019-06-201-28/+1
| | | | | | | | | | | | | | | | There is no need to check for ALLOC function failures in the code base. If we cannot get more memory we assert. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* | Revert "Ospf missing interface handling 2"Donald Sharp2019-06-241-4/+3
| |
* | Merge pull request #3775 from pguibert6WIND/ospf_missing_interface_handling_2Donald Sharp2019-06-221-3/+4
|\ \ | | | | | | Ospf missing interface handling 2
| * | *: change interface structure, from vrf_id to vrfPhilippe Guibert2019-06-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Field vrf_id is replaced by the pointer of the struct vrf *. For that all other code referencing to (interface)->vrf_id is replaced. This work should not change the behaviour. It is just a continuation work toward having an interface API handling vrf pointer only. some new generic functions are created in vrf: vrf_to_id, vrf_to_name, a zebra function is also created: zvrf_info_lookup an ospf function is also created: ospf_lookup_by_vrf it is to be noted that now that interface has a vrf pointer, some more optimisations could be thought through all the rest of the code. as example, many structure store the vrf_id. those structures could get the exact vrf structure if inherited from an interface vrf context. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
| * | lib, bgpd, ospfd, pimd, zebra, rip, ripng, bfd: change ↵Philippe Guibert2019-06-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | if_update_to_new_vrf() api vrf_id parameter is replaced with struct vrf * parameter. It is needed to create vrf structure before entering in the fuction. an error is generated in case the vrf parameter is missing. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
| * | *: change if_lookup_by_name() api with vrfPhilippe Guibert2019-06-121-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the vrf_id parameter is replaced by struct vrf * parameter. this impacts most of the daemons that look for an interface based on the name and the vrf identifier. Also, it fixes 2 lookup calls in zebra and sharpd, where the vrf_id was ignored until now. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* | | 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/+16
|/ | | | | | | Add some debugs so we can see channel oil creation and deletion events. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* Merge pull request #4112 from pguibert6WIND/bfd_vrfRafael Zalamena2019-05-141-1/+1
|\ | | | | support for BFD VRF
| * bgp, ospfd, ospf6d, pimd, lib, isisd: add bfd_client_sendmsg vrf_idPhilippe Guibert2019-05-071-1/+1
| | | | | | | | | | | | | | vrf_id parameter is added to the api of bfd_client_sendmsg(). this permits being registered to bfd from a separate vrf. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* | Merge pull request #4214 from donaldsharp/s_g_channel_deletionJafar Al-Gharaibeh2019-05-101-2/+10
|\ \ | |/ |/| pimd: Deletion of a ifchannel does not immediately mean remove from OIL
| * pimd: Deletion of a ifchannel does not immediately mean remove from OILDonald Sharp2019-04-241-2/+10
| | | | | | | | | | | | | | | | | | So when we remove a ifchannel from the system we should check to see if we still care about the S,G having it in the OIL still due to inheritance rules. The deletion does not necessarily mean it should not be in the OIL for the S,G. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* | *: use ZAPI_CALLBACK_ARGS macro for zapi handlersQuentin Young2019-05-031-22/+13
|/ | | | | | | | | | | | 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>
* pimd: setup multicast vxlan tunnel termination deviceAnuradha Karuppiah2019-04-201-0/+9
| | | | | | | | | | | | | | | | | | | An interface needs to be designated as "termination device" and added to the termination mroute's OIL. This is used by kernel and ASIC backends to vxlan-decaps matching flows. The default termination device is expected to have the prefix (start sub-string) "ipmr-lo". This can be made configurable if needed - root@TORS1:~# ip -d link show ipmr-lo 28: ipmr-lo: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default link/ether 12:5a:ae:74:51:a2 brd ff:ff:ff:ff:ff:ff promiscuity 0 dummy addrgenmode eui64 root@TORS1:~# ip mr This commit includes the changes to enable pim implicitly on the device and set it up as the vxlan-term device per-pim-instance. Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-21 03:07:48 +0100