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>
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>
This is as per RFC. This is identified when conformance suite catched join.
RCA:
Packets were processed without checking allowed dest IP for that packet.
Fix:
Added check for dest IP
Converted this check to a function
Signed-off-by: Saravanan K <saravanank@vmware.com>
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>
If a register packet is received that is less than the PIM_MSG_REGISTER_LEN
in size we can have a possible situation where the data being
checksummed is just random data from the buffer we read into.
2019/11/18 21:45:46 warnings: PIM: int pim_if_add_vif(struct interface *, _Bool, _Bool): could not get address for interface fuzziface ifindex=0
==27636== Invalid read of size 4
==27636== at 0x4E6EB0D: in_cksum (checksum.c:28)
==27636== by 0x4463CC: pim_pim_packet (pim_pim.c:194)
==27636== by 0x40E2B4: main (pim_main.c:117)
==27636== Address 0x771f818 is 0 bytes after a block of size 24 alloc'd
==27636== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27636== by 0x40E261: main (pim_main.c:112)
==27636==
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This will facilitate the Hardware to prefer control packets over
Normal Data packets while queuing, so that during congestion, the
chance of dropping control packet will be minimised.
Signed-off-by: Satheesh Kumar K <sathk@cumulusnetworks.com>
1. Packet validation as per RFC 5059 Sec 3.1.3
We won't supporting scope zone BSM as of now, they are dropped now.
Order of the check slightly be changed in code for optimization.
if ((DirectlyConnected(BSM.src_ip_address) == FALSE) OR
(we have no Hello state for BSM.src_ip_address)) {
drop the Bootstrap message silently
}
if (BSM.dst_ip_address == ALL-PIM-ROUTERS) {
if (BSM.no_forward_bit == 0) {
if (BSM.src_ip_address != RPF_neighbor(BSM.BSR_ip_address)) {
drop the Bootstrap message silently
}
} else if ((any previous BSM for this scope has been accepted) OR
(more than BS_Period has elapsed since startup)) {
#only accept no-forward BSM if quick refresh on startup
drop the Bootstrap message silently
}
} else if ((Unicast BSM support enabled) AND
(BSM.dst_ip_address is one of my addresses)) {
if ((any previous BSM for this scope has been accepted) OR
(more than BS_Period has elapsed since startup)) {
#the packet was unicast, but this wasn't
#a quick refresh on startup
drop the Bootstrap message silently
}
} else {
drop the Bootstrap message silently
}
2. Nexthop tracking registration for BSR
3. RPF check for BSR Message.
Zebra Lookup based rpf check for new BSR
NHT cache(pnc) based lookup for old BSR
Signed-off-by: Saravanan K <saravanank@vmware.com>
This commit includes parsing of Nbit and contructing pim hdr with Nbit
Adding Nbit to PIm hdr structure
Adding Scope zone bit and Bidir bit to Encoded IPv4 Group Address
Signed-off-by: Saravanan K <saravanank@vmware.com>
Create a `struct pim_router` and move the thread master into it.
Future commits will further move global varaibles into the pim_router
structure.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
End user was seeing this debug but we are not giving
the user enough information to debug this on his own.
Add a tiny bit of extra information that could point
the user to solving the problem for themselves.
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>
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>
