Modifying name of struct igmp_sock to struct gm_sock, which is to be used
by both IPv4 and IPv6(for both MLD and IGMP).
Co-authored-by: Mobashshera Rasool <mrasool@vmware.com>
Co-authored-by: Sarita Patra <saritap@vmware.com>
Signed-off-by: Sai Gomathi <nsaigomathi@vmware.com>
Fix:
====
Modifying name of struct igmp_join to struct gm_join, which is to be used
by both IPv4 and IPv6(for both MLD and IGMP).
Co-authored-by: Abhishek N R abnr@vmware.com
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Modifying the members of pim_interface which are to be used
for both IPv4 and IPv6 to common names(for both MLD and IGMP).
Issue: #10023
Co-authored-by: Mobashshera Rasool <mrasool@vmware.com>
Signed-off-by: Sai Gomathi <nsaigomathi@vmware.com>
Since f60a1188 we store a pointer to the VRF in the interface structure.
There's no need anymore to store a separate vrf_id field.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
It allows FRR to read the interface config even when the necessary VRFs
are not yet created and interfaces are in "wrong" VRFs. Currently, such
config is rejected.
For VRF-lite backend, we don't care at all about the VRF of the inactive
interface. When the interface is created in the OS and becomes active,
we always use its actual VRF instead of the configured one. So there's
no need to reject the config.
For netns backend, we may have multiple interfaces with the same name in
different VRFs. So we care about the VRF of inactive interfaces. And we
must allow to preconfigure the interface in a VRF even before it is
moved to the corresponding netns. From now on, we allow to create
multiple configs for the same interface name in different VRFs and
the necessary config is applied once the OS interface is moved to the
corresponding netns.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Problem Statement:
==================
On new neighbor addition, the tx counter for hello msg is reset.
Fix:
=================
Do not reset the tx counter on new neighbor addition.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Problem Statement:
==================
pim maintains two counters hello tx and hello rx at interface level.
At present pim needs to send the hello message prior to other pim
message as per RFC. This logic is getting derived from the tx hello
counters. So when a new neighbor is added, tx counters are set to
zero and then based on this, it is further decided to send hello in
pim_hello_require function.
Fix:
====
Separating the hello statistics and the logic to decide when to send hello
based on a new flag. pim_ifstat_hello_sent will be used to note down
the hello stats while a new flag is added to decide whether to send hello
or not if it is the first packet to a neighbor.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
IGMP group/source memberships are a property of the interface; the
particular IP address that the querier used to collect the data is
irrelevant.
... and IGMP packets get delivered only once to pimd anyway, since we
receive them on the "global" per-VRF IGMP socket. (The one in igmp_sock
is only used for sending queries.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
When we have a "192.0.2.1 peer 192.0.2.2/32" address on an interface, we
need to (a) recognize the local address as being on the link for our own
packets, and (b) do the IGMP socket lookup with the proper local address
rather than the peer prefix.
Fixes: efe6f18 ("pimd: fix IGMP receive handling")
Cc: Nathan Bahr <nbahr@atcorp.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
VRF creation can happen from either cli or from
knowledged about the vrf learned from zebra.
In the case where we learn about the vrf from
the cli, the vrf id is UNKNOWN. Upon actual
creation of the vrf, lib/vrf.c touches up the vrf_id
and calls pim_vrf_enable to turn it on properly.
At this point in time we have a pim->vrf_id of
UNKNOWN and the vrf->vrf_id of the right value.
There is no point in duplicating this data. So just
remove all pim->vrf_id and use the vrf->vrf_id instead
since we keep a copy of the pim->vrf pointer.
This will remove some crashes where we expect the
pim->vrf_id to be usable and it's not.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When creating configuration for a vrf *Before* the vrf has been
created, pim will not properly create the pimreg device and
we will promptly crash when we try to pass data.
Put some code checks in place to ensure that the pimreg is
created for vrf's.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
IGMP packets received from a source that does not match the subnet
of any configured addresses on the receive interface should be
ignored.
Also, find and use the correct IGMP socket object for the received
IGMP packet.
Signed-off-by: Nathan Bahr <nbahr@atcorp.com>
Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
Suppose you have more than 2 addresses on a pim interface:
lo up default 10.255.0.1/32
10.255.0.101/32
10.255.0.254/32
A `show ip pim int lo` gives us this:
eva# show ip pim interface lo
Interface : lo
State : up
Address : 10.255.0.1 (primary)
10.255.0.101/32
When we go look at the code that pulls secondary addresses in
we are using a prefix_cmp to know if we know about a secondary already
but were expecting true values instead of -1/0/1 being returned.
Modify code so that pim sees all secondary addresses
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Replace all `random()` calls with a function called `frr_weak_random()`
and make it clear that it is only supposed to be used for weak random
applications.
Use the annotation described by the Coverity Scan documentation to
ignore `random()` call warnings.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
RCA: Upstreams which are in register state other than noinfo, doesnt remove
register tunnel from oif after it becomes nonDR
Fix: scan upstreams with iif as the old dr and check if couldReg becomes false.
If couldreg becomes false from true, remove regiface and stop reg timer.
Do not disturb the entry. Later the entry shall be removed by kat expiry.
Signed-off-by: Saravanan K <saravanank@vmware.com>
RCA: This was todo item in current code base
Fix: Hello sent with 0 hold time before we update the pim ifp primary address
Signed-off-by: Saravanan K <saravanank@vmware.com>
RCA:
Trying to get primary address for the interface.
Unnumbered interface pick address from vrf device for non default.
While doing so it ends up in recursion without exit condition if vrf dev doesnt have any address.
Solution:
Break the recursion by checking if it is vrf device.
Signed-off-by: Saravanan K <saravanank@vmware.com>
RCA: When configured more than 32(MAXVIS), the inerfaces that are configured
after 32nd interfaces have the value of MAXVIF.
This is used as index to access the free vif tracker of array size 32(MAXVIFS).
So the channel oil list pointer which is present as the next field in pim structure get corrupt, when updating free vif.
This gets accessed during rpf update resulting in crash.
Fix: Refrain from allocating mcast interface structure and throw config error when more than MAXVIFS are attempted to configure.
Max vif checks are exempted for vrf device and pimreg as vrf device will be the first interface and not expected to fail and pimreg has reserved vif.
vxlan tunnel termination device creation has this check and throw warning on max vif.
All other creation are through CLI.
Signed-off-by: Saravanan K <saravanank@vmware.com>
ipmr-lo is an internally added device used for multicast vxlan tunnel
termination. This device is not expected to be managed by the admin
however in the case it is accidentally shut we need to be able handle
it by recovering when it is "no shut" again.
Ticket: CM-24985
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Commit: ddbf3e6060
This commit modified the interface up handling code in
ZAPI such that the zclient handled the decoding for you.
Prior to this commit ospf assumed that it could use the
old ifp pointer to know state before reading the stream.
This lead to a situation where ospf would `smartly` track
and do the right thing in this situation. This commit
changed this assumption and in certain scenarios, say
a interface was changed after it was already up would
lead to situations where ospf would not properly handle
the new interface up.
Modify ospf to track data that is important to it in
it's interface->info pointer.
This code pattern was followed in both eigrp and pim.
In eigrp's case it was just behaving weirdly in any event
so fixing this pattern is not a big deal. In pim's
case it was not properly using this so it's a no-op
to fix.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Cleanup the interface creation apis to make it more
clear what they are doing.
Make it explicit that the creation via name/ifindex will
only add it to the appropriate list.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
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 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>
Start the conversion to allow zapi interface callbacks to be
controlled like vrf creation/destruction/change callbacks.
This will allow us to consolidate control into the interface.c
instead of having each daemon read the stream and react accordingly.
This will hopefully reduce a bunch of cut-n-paste stuff
Create 4 new callback functions that will be controlled by
lib/if.c
create -> A upper level protocol receives an interface creation event
The ifp is brand spanking newly created in the system.
up -> A upper level protocol receives a interface up event
This means the interface is up and ready to go.
down -> A upper level protocol receives a interface down
destroy -> A upper level protocol receives a destroy event
This means to delete the pointers associated with it.
At this point this is just boilerplate setup for future commits.
There is no new functionality.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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>
Introduce new cli commands ip igmp last-member-query-count <1-7>
ip igmp last-member-query-interval <1-255> deciseconds.
Display the config in show running config and show ip igmp interface
Signed-off-by: Sarita Patra <saritap@vmware.com>
For vxlan origination mroutes the IIF is pinned to
a. lo for single VTEPs
b. peerlink-rif for anycast VTEPs
This commit includes the changes to react to pim-vifi add/del for these
devices.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
ipmr-lo is a dummy netdev with no additional addressing requirements -
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:~#
This device is used by pim-vxlan to signify multicast-vxlan-tunnel
termination.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Add a command to track if an interface should be in active-active
mode or not. This command is hidden at this time because it
is not finished fully.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
In pim_if_new use bool instead of an int to pass
true/false values for what we should create the
pim interface type for.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The startup of a non-integrated config was not properly
allowing for startup to create the vif when we have
not learned about the interface we are trying to configure
at this point in time. Actually notice when we are
trying to create a pimreg device or not to properly
notice when to attempt to create the vif or not.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The pim_socket_join_source function only ever calls
pim_igmp_join_source and pim_socket_join_source is only
called from 1 place. Skip the level of indirection.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The interface itself knows if it is a vrf device or
not, so let's just use a check for that in the decision
if a interface is a loopback or not.
Additionally modify function to return a bool.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Feature of mtrace only IGMP sockets on pim sm and pim
ssm interfaces. Modifed IGMP socket creation and show
igmp interface command output.
Signed-off-by: Mladen Sablic <mladen.sablic@gmail.com>
When creating the pim_ifp, and we run out of memory there
existed a chance that we would dereference the failed memory
pointer.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
A recent commit has shown that we were not consistent with
handling of the vrf lookup. Adjust pim to do the right
thing with vrf lookup to be consistent and to make SA
happier.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This improves code readability and also future-proofs our codebase
against new changes in the data structure used to store interfaces.
The FOR_ALL_INTERFACES_ADDRESSES macro was also moved to lib/ but
for now only babeld is using it.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This is an important optimization for users running FRR on systems with
a large number of interfaces (e.g. thousands of tunnels). Red-black
trees scale much better than sorted linked-lists and also store the
elements in an ordered way (contrary to hash tables).
This is a big patch but the interesting bits are all in lib/if.[ch].
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Make use of strnlen() and strlcpy() so we can get rid of these
convoluted if_*_by_name_len() functions.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
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>
Adds the ability to filter PIM Joins & IGMP reports on an interface.
Enabling a multicast boundary on an interface for a particular group
will prevent the interface from appearing in the group's OIL.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
If you cut-n-paste an existing "ip igmp join 233.200.0.0 0.0.0.0"
command under an interface we should not return an error.
This fixes the broken indentation of several foreach loops throughout
the code.
From clang's documentation[1]:
ForEachMacros: A vector of macros that should be interpreted as foreach
loops instead of as function calls.
[1] http://clang.llvm.org/docs/ClangFormatStyleOptions.html
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Start the conversion of pim configuration commands to use
the ferr side channel to allow more detailed information
to be returned to cli commands.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The secondary address list was being added/removed as
we went. I see no reason to have special bookkeeping
for this list. Just add it on interface startup and
then remove it on deletion. Removes some
very specialized coding that was saving a very small
amount of space.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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>
This patch does two things:
1) Converts the pim_ifp->ifchannel_list to a pim_ifp->ifchannel_rb
2) Removes the hashing to use the RB RB_FIND instead.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Remove the redundant information in pim_ifp->pim_ifchannel_list
just call it pim_ifp->ifchannel_list
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The pim->ifchannel_list can be duplicated by iterating
over each vrf and then over each pim_ifp->pim_ifchannel_list
Since list handling is taking allot of time at scale
convert over to using this value.
Additionally clean up pim_cmd.c to have helper functions
to handle the actual encoding of data for output.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When the secondary addresses got expanded to allow
v6 on the list, we needed to limit the igmp sockets
to just v4 currently.
Ticket: CM-16858
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Quentin Young <qlyoung@cumulusnetworks.com>
Under vrf's pim needs to have a socket listening for pim packets on the vrf
device so that we can actually get the packets. As such when we configure
up a vrf interface, configure just enough to allow it to listen on the
device and to do the right thing.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Bind the pim kernel fd to the appropriate vrf, modify
the callback up into pim with the IGMP report to
retrieve the incoming interface and use that to
lookup the correct interface to use.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The vrf loopback ip address should be associated with the
vrf device for vrf's, else use the loopback.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Move the upstream_list, hash and wheel into 'struct pim_instance'
Remove all pimg to pim in pim_upstream
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
1) Create pim_instance.[ch] to allow us to handle the instance information there
2) Refactor some pim_rpf_ and some pim_rp commands into appropriate files and
appropriate includes.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The pimreg device name should be based upon the
tableid we create( as that this is what the kernel does )
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Storing the pim instance off of the pim interface will allow
us to easily keep track of vrf information. This is because
pretty much is everything is interface based.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
