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>
It is possible that the incoming interface lookup
will fail because we are in transition from one vrf
to another.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we are initializing a pim socket for vrf or loopback
interfaces do not schedule a hello to go out at all.
I'm currently leaving the check on is a vrf / loopback
device on the actual send as that we have several paths
to get there.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
In a vrf configuration, when we receive a pim packet we lookup
the correct incoming interface. There exists a chance that
the correct incoming interface has not been configured to use
pim yet. gracefully bow out and do nothing with the packet.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The vrf interface is receiving the pim packet
instead of the slave interface that is bound.
Lookup the ifindex ifp pointer from that.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we add a thread pointer to thread_add_XXX functions
when the specified function is called, thread.c is setting
the thread pointer to NULL. This was causing pim to
liberally pull it's zassert grenade pin's.
Additionally clean up code to not set the NULL pointer.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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>
The way thread.c is written, a caller who wishes to be able to cancel a
thread or avoid scheduling it twice must keep a reference to the thread.
Typically this is done with a long lived pointer whose value is checked
for null in order to know if the thread is currently scheduled. The
check-and-schedule idiom is so common that several wrapper macros in
thread.h existed solely to provide it.
This patch removes those macros and adds a new parameter to all
thread_add_* functions which is a pointer to the struct thread * to
store the result of a scheduling call. If the value passed is non-null,
the thread will only be scheduled if the value is null. This helps with
consistency.
A Coccinelle spatch has been used to transform code of the form:
if (t == NULL)
t = thread_add_* (...)
to the form
thread_add_* (..., &t)
The THREAD_ON macros have also been transformed to the underlying
thread.c calls.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
There exists a common pattern in pim where we were setting
a variable to a value in the error case when we would no
longer need it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Send v6 secondary addresses to our neighbor in hello's.
Additionally allow the disabling it via the cli introduced
earlier.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we get a packet from the network for pim, we do not
need to check to see that it is a pim packet, since that
is what we've asked to receive.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
For:
pim_msg_build_header
pim_msg_addr_encode_ipv4_ucast
pim_msg_addr_encode_ipv4_group
pim_msg_addr_encode_ipv4_source
Assume that the buffer size passed in is of sufficient size
already. This is assured already because buffer sizes
are checked for minimum lengths for the entire packet
ahead of time. So we are double checking.
Additionally at scale we will be calling these functions
a very very large number of times.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add the 'struct pim_msg_header' and convert
all places that encoded/decoded the message header
to use it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket:CM-12924
Reviewed By:shapd
Testing Done: configure PIM neighbor, verify PIM hello packet dump for ttl to be 1.
Set TTL to 1 for outgoing multicast control packets destine to ALL-PIM-ROUTERS as oppose to unicast mcast packets.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Ticket: CM-12041
Reviewed By: sharpd, CCR-5556
Testing Done: Tested on Local setup generating PIM Register (Data/Null) and processing both Tx/Rx with correct checksum.
Provided quagga debian to submitter and checksum cases passed on submitter setup.
1. PIM Register msg checksum only accounts for 8 bytes (4 bytes for PIM header and next 4 byetes before data payload).
In PIM header checksum calculation checked PIM packet type (in this case REGISTER type) then only pass 8 bytes as length
rather than full packet length.
2. PIM Register Rx path also handled with 8 byte and full pim lenth checksum.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
In all cases pim_sock_open was called, we just passed
in the pim_ifp->primary_address, which is accessible
from the interface pointer. So just pass that in.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This fixes the issue a crash when we have configured an interface
inside of a vrf, and apply pim commands to it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we receive a packet from a neighbor, reset the
hold time as that we *know* that they are still
alive.
During heavy packet load, we were seeing cases
where neighbors were being reset because we
were timing out due to not processing the hello
packet in time.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
In certain error conditions it is possible to
attempt to send packets when the socket is not ready
instead of dumping to the log a million error messages
only note the issue if we have packet debugs on.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
There exists situations where an interface flaps
and routing recovers and we attempt to install
an upstream but since we have no neighbor out
that interface still. Let's cause the hello
to go out immediately for the 3.1 release
to allow mrouting to recover in this situation.
We will need to revisit this issue after
we have proper nexthop tracking in place
Ticket: CM-13185
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Add 'ip pim packets <1-100>' command.
Allows you to control the number of packets read in before
giving control back to another part of the process.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we received a packet we were dumping packet information
with debugs on 2 times for each packet where we had overlapping
data being passed.
Since debugs are expensive, reduce the count to 1.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Cleanup some turned on debug code that is no longer
needed to be turned on in the pim_sock_read
code path.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we handle the thread arguments,
there is no need to assert. As that
if they are wrong, we are going down
shortly anyways.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When receiving callbacks from the kernel allow bigger
packet sizes than 3k to be handled appropriately.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When a interface goes down we accidently put ourselves into
an infinite loop.
Ticket: CM-12803
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When sending register packets to the RP from the FHR
we should be using the ip address of the incoming interface
that received the mcast packet.
Ticket: CM-12445
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Change the pim message type to an enum and add the ability
to output a string based upon message type.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Implement the pim_register_stop state machine. There are still a few
bugs still but this is enough to get us rolling a bit more.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
We were using a variety of techniques to handle
incoming pim packets. Refactor to use a switch
statement to handle the incoming packets.
Also add the ability to notice that we are getting
a register stop.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When receiving packets and the parse fails
a zlog_err is generated. This should be
protected by a debug.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When pim is receiving packets, each interface's fd is receiving
packets for all interfaces. Modify the code to bind the
pim interface sockets to the interface they were created for.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This code prevents pim from forming a neighbor relationship
with itself by preventing pim from sending a hello
out the loopback interface if we have pim configured
on an interface.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Allow pim to separate out the pim vif index from the ifindex.
This change will allow pim to work with up to 255(MAXVIFS)
interfaces, while also allowing the interface ifindex to
be whatever number it needs to be.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Valgrind is reporting that pimd is using uninitialized
memory for comparisons. This commit addresses
the issues found there.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This code starts the handling of the pim register type. No guarantees that
it works correctly, just that it compiles and the start of the code is in there.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
pimd was outputting allot of data surrounding pim hello packets.
In addition the debugging was inconsistent and not all turned
on via 'debug pim packet hello'.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
There are PIM packet types that have not been implemented yet.
Notice when we get one of those and safely do nothing.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When caling pim_sock_open if the failure cause happens, however
unlikely, don't leak the fd on failure.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The RFC states that an interfaces generation_id must be changed
if it experiences an if down. From 4.3.1:
The GenID option contains a randomly generated
32-bit value that is regenerated each time PIM forwarding is started
or restarted on the interface, including when the router itself
restarts.
Since we are only grabbing a new generation_id without comparing
it to the previous generation_id, it is possible that random
can generate the exact same number.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The DR election is occurring on every hello received.
This is because the hello receive packet returns a 0
for any successfully received packet. PIMD then looked
at the 0 returned and did a DR election.
Code was inspected for the cases where DR should happen:
(A) Interface ip address change
(B) DR priority in hello packet changes
(C) Received a new neighbor on an interface
(D) Neighbor timer pops.
Each of these initiate a DR election in the code currently.
Testing was initiated on a pim network:
tor-11# show ip pim designated-router
NonPri: Number of neighbors missing DR Priority hello option
Interface Address DR Uptime Elections Changes NonPri
br1 20.0.15.1 20.0.15.1 00:08:16 1 1 0
swp1 169.254.0.10 169.254.0.10 00:08:16 2 1 0
swp2 169.254.0.26 169.254.0.26 00:08:16 2 1 0
tor-11#
As you can see Elections == 2. This is because pimd performs
an election on (A) and (C) above. I see no need to modify
(A) to check if we have any knowledge of the interface before
this call.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
pimd rolled it's own solution to random #'s, that was not
terribly random. Rely on the underlying system to generate
random #'s for us
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
While glibc seems to have something in the system headers that prevents
this from triggering a warning, FreeBSD doesn't. Fix the warning.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Welcome pimd to the Quagga daemon zoo!
This is a merge of commit 77ae369 ("pimd: Log ifindex found for an
interface when zebra lib reports a new connected address."), with
the intermediate "reconnect" changes removed (c9adf00...d274381).
d274381 is replaced with b162ab7, which includes some changes. In
addition, 4 reconnect-related changes and 1 cosmetic one have been
bumped out.
The rebase command used to produce the branch that is merged here is:
git rebase --onto b162ab7 c9adf00 77ae369
Note that 3 patches had their author rewritten from
"Anonymous SR#108542 <>" (which is not a valid git author ID)
to: "Savannah SR#108542 <nbahr@atcorp.com>" (which is the e-mail address
listed in the associated Savannah ticket)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
