Line break at the end of the message is implicit for zlog_* and flog_*,
don't put it in the string. Mid-message line breaks are currently
unsupported. (LF is "end of message" in syslog.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Problem: This happened in once in a while during testing the scenario multiple
times. When regstop timer expire and at that point if rpf interface doesn't
exist, the register state for the upstream gets struck in reg-prune state indefinitely.
This will not recover even when rpf comes back and traffic resumed because
register state is struck on prune.
RCA: Reg suppression expiry is keeping reg state unchanged when iif is absent.
Fix: When iif is absent during reg suppression expiry, treat it as couldreg
becoming false and move it NO_INFO state.
Signed-off-by: Saravanan K <saravanank@vmware.com>
Problem: output is cut short when prefix string all octets are 3 digit.
RCA: Buffer was allocated only to hold ip addr str.
Fix: Added 3 bytes more to hold prefix length and a /.
Modified buffer in 'show ip pim bsrp-info' and 'show ip pim bsm database'
Signed-off-by: Saravanan K <saravanank@vmware.com>
Zebra is currently sending messages on interface add/delete/update,
VRF add/delete, and interface address change - regardless of whether
its clients had requested them. This is problematic for lde and isis,
which only listens to label chunk messages, and only when it is
waiting for one (synchronous client). The effect is the that messages
accumulate on the lde synchronous message queue.
With this change:
- Zebra does not send unsolicited messages to synchronous clients.
- Synchronous clients send a ZEBRA_HELLO to zebra.
The ZEBRA_HELLO contains a new boolean field: sychronous.
- LDP and PIM have been updated to send a ZEBRA_HELLO for their
synchronous clients.
Signed-off-by: Karen Schoener <karen@voltanet.io>
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: preferred bsr routine, compare address in network byte order
Fix: changed to host format before comparision.
Testing:
Verified between 1.1.2.7 and 10.2.1.1, 10.2.1.1 is chosen as bsr
Initially:
R11# sh ip pim bsr
PIMv2 Bootstrap information
Current preferred BSR address: 1.1.2.7
Priority Fragment-Tag State UpTime
0 2862 ACCEPT_PREFERRED 00:00:30
Last BSM seen: 00:00:30
After next bsr started:
R11# sh ip pim bsr
PIMv2 Bootstrap information
Current preferred BSR address: 10.2.1.1
Priority Fragment-Tag State UpTime
0 3578 ACCEPT_PREFERRED 00:00:01
Last BSM seen: 00:00:01
R11# sh ip pim bsr
PIMv2 Bootstrap information
Current preferred BSR address: 10.2.1.1
Priority Fragment-Tag State UpTime
0 3578 ACCEPT_PREFERRED 00:00:04
Last BSM seen: 00:00:04
Signed-off-by: Saravanan K <saravanank@vmware.com>
Problem:
When the ifchannel is in SGRpt prune, if we receive a join, we go into no info
state but mroute still present with none oil
Join Prune Expiry timer on the ifchannel was still running when
Prune pending expired. This causes ifchannel not to be deleted and hence mroute.
Fix:
Stop expiry timer when we move into NOINFO state and delete the ifchannel.
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:
Either JP timer is used to send join or join timer.
We are not removing the group from jp aggregate during suppression.
So even if join timer is restarted, jp aggregate expiry during suppression
is sending join for the group.
Fix:
Remove the group from jp aggregate on the neighbor during jp suppression.
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: starg join fell in to SGRpt join check and was treated as SGRpt join
so ifchannel state machine moved from prunepending to noinfo.
Fix: Check if it is starg join and process
Signed-off-by: Saravanan K <sarav511@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:
It has asserted because during neighbor delete on a interface,
pim_number_of_nonlandelay_neighbors count has become less less than 0.
This was due to not updating the count when hello option changed.
Fix:
During hello option update, check and increment or decrement when this option changes.
Signed-off-by: Saravanan K <saravanank@vmware.com>
RCA:
1. Prune processing during join state was putting of join expiry timer
2. Join received during prune pending state was not comparing hold time with remaining expiry timer.
Fix:
Fixed as per RFC 4601/7761
Signed-off-by: Saravanan K <saravanank@vmware.com>
RCA: We are ignoring (*,G) prune when the RP in packet is not RP(G)
Fix:
According to RFC 4601 Section 4.5.2:
Received Prune(*,G) messages are processed even if the RP in the message does not match RP(G).
We have allowed starg prune to be processed in the scenario.
Signed-off-by: Saravanan K <saravanank@vmware.com>
RCA: Periodic join is mostly sent by nbr jp timer except for few scenarios by upstream join timer
Fix: If join timer not running, we have to use nbr jp timer to calculate
remaining time for next join.
Signed-off-by: Saravanan K <saravanank@vmware.com>
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>
Issue 1: "show ip pim interface traffic" not show prune TX/RX
Rootcause : not added the variable in the json
Fix : add prune TX/RX in show ip pim interface traffic json
Issue 2: "show ip pim rp-info" not shows the key iAmRp when it is false
Rootcause: Only display the key when the value is true.
Fix: add iAmRp as false in show ip pim rp-info json
Issue 3: "show ip pim rp-info" not showing outbound interface if it is empty
Rootcause: Only display when there is any OIL
Fix: When RP is not reachable then, the outbound interface is Unknown
The command "show ip pim rp-info json" not displaying the outbound
interafce if it is unknown
Signed-off-by: Sarita Patra <saritap@vmware.com>
S - Sparse Mode
C - indicates there is a member of the group directly connected to the router.
R -set on an (S, G) by the receipt of an (S, G) RP bit prune message.
F -This indicates that this router is a FHR and send register messages to RP to inform RP of this active source
P - OIL list is NULL. That means the router will send a prune.
T - At least one packet received via SPT.
Signed-off-by: Sarita Patra <saritap@vmware.com>
Problem:
We are receiving PIM BSR packet over the pim interface which has no nbrs
According to RFC 5059 Sec 3.4
When a Bootstrap message is forwarded, it is forwarded out of every
multicast-capable interface that has PIM neighbors (including the one
over which the message was received).
RCA:
We are sending to all pim neighbors.
Fix:
We will avoid the interfaces which has no neighbors.
Verification: Manually verified that Pim router doesn't forward to intf with no nbrs
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>
Problem: Route node is not de referenced after search when pim debug events are
not enabled when pim_rp_find_match_group is called. So this memory will not get
released when route node is deleted after hitting this path.
RCA: Dereferencing is done inside debug condition.
Fix: Moving outside debug condition
Signed-off-by: Saravanan K <saravanank@vmware.com>
Root cause: The header display is put in common outside the vtysh/json if-else.
Fix: Brought inside vtysh condition.
Signed-off-by: Saravanan K <saravanank@vmware.com>
Issue: when (*,G) has some receiver and directly connected source sends traffic,
new (S,G) entry created is not inheriting the oil from (*,g)
RCA: pim_mroute_msg_nocache haven't assume FHR have (*,g) member ports
Fix : Added inherit oil from parent from (*,g) receivers to get added
Signed-off-by: Saravanan K <saravanank@vmware.com>
Issue: When any interface is getting added/deleted in the outgoing
interface list, it calls pim_mroute_add() which is updating the
mroute_creation time without checking if the mroute is already
installed in the kernel.
Fix: Check if mroute is already installed, then dont refresh the
mroute_creation timer.
Signed-off-by: Sarita Patra <saritap@vmware.com>
Issue: show ip mroute displays the mroute uptime (time when
mroute installed into the kernel) per oif.
This is confusing.
Fix: Display mroute uptime per (s,g) mroute entry.
Signed-off-by: Sarita Patra <saritap@vmware.com>
There exists a chain of events where calling pim_mlag_up_peer_deref
can free the up pointer. Prevent a use after free by returning
the up pointer as needed and checking to make sure we are
ok.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
On shutdown processing we may have gotten a interface down event
which might clear the rpf interface and we might trigger a
work queue item on the vxlan_sg to send a NULL register.
Ensure that we cannot attempt to do the impossible.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
VRF deletion events here calling hash_clean() with
nothing to clean up the vxlan_sg's associated with it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When pim receives a register packet, we will apply the
received source to the prefix list. If accepted normal
processing continues. If denied we will send a register
stop message to the source.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
We already use the pim pointer a bunch off of pim_ifp->pim
just add another pim variable to allow us to shorten code
a bit.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The memory type PIM_SPT_PLIST_NAME is specific to
SPT but we are going to store more prefix-list names
in pim, make it generic to allow for less confusion
in the future.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When the (S,G) KAT expires we need to poll for activity before dropping the
entry as traffic may have been forwarded by the dataplane since the last
periodic poll cycle.
This only works if traffic is being forwarded by the kernel i.e. if the
entries were HW accelerated via an ASIC we may still miss out on last
minute activity on the mroute in the HW.
Ticket: CM-26871
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
An mroute can transition from non-origination to a vxlan origination
mroute. In that case we need to re-evaluate if the interfaces in the
OIL need to be muted; pimreg and termination device need to be muted (if
they were previously un-muted).
Dump in a problem state:
=======================
root@TORC11:~# net show pim state
Codes: J -> Pim Join, I -> IGMP Report, S -> Source, * -> Inherited from (*,G), V -> VxLAN, M -> Muted
Active Source Group RPT IIF OIL
1 * 239.1.1.100 y uplink-1 pimreg(I ), ipmr-lo( J )
1 36.0.0.11 239.1.1.100 n peerlink-3.4094 ipmr-lo( * ), uplink-1( J ), uplink-2( J ), peerlink-3.4094( V )
PS: ipmr-lo should have M set in (36.0.0.11,239.1.1.100)
Ticket: CM-26747
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Add a special catch to the test for pim_macro_chisin_pim_include
to allow the LHR to signal interest in joining upstream.
This will allow both the DR and non DR of the ActiveActive
situation to draw traffic to itself.
The non-DR will continue to not forward traffic.
Ticket: CM-26610
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Series of events leading to the problem -
1. (S,G) has been pruned on the rp on downlink-1
2. a (*,G) join is rxed on downlink-1 without the source S. This
results in the (S,G,rpt) prune state being cleared on downlink-1.
As a part of the clear the ifchannel associated with downlink-1
is deleted.
3. The ifchannel_delete handling is expected to add downlink-1
as an inherited OIF to the channel OIL (which it does). However
it is also added in as an immediate OIF (accidentally) as the
ifchannel is still present (in the process of being deleted).
To avoid the problem defer pim_upstream_update_join_desired
evaluation until after the channel is deleted.
Relevant debug logs -
PIM: pim_ifchannel_delete: ifchannel entry (27.0.0.15,239.1.1.106)(downlink-1) del start
PIM: pim_channel_add_oif(pim_ifchannel_delete): (S,G)=(27.0.0.15,239.1.1.106): proto_mask=4 OIF=downlink-1 vif_index=7: DONE
PIM: pimd/pim_oil.c pim_channel_del_oif: no existing protocol mask 2(4) for requested OIF downlink-1 (vif_index=7, min_ttl=1) for channel (S,G)=(27.0.0.15,239.1.1.106)
PIM: pim_upstream_switch: PIM_UPSTREAM_(27.0.0.15,239.1.1.106): (S,G) old: NotJoined new: Joined
PIM: pim_channel_add_oif(pim_upstream_inherited_olist_decide): (S,G)=(27.0.0.15,239.1.1.106): proto_mask=2 OIF=downlink-1 vif_index=7 added to 0x6 >>>>>>>>>>>>>>>>>>
PIM: pim_upstream_del(pim_ifchannel_delete): Delete (27.0.0.15,239.1.1.106)[default] ref count: 2 , flags: 81 c_oil ref count 1 (Pre decrement)
PIM: pim_ifchannel_delete: ifchannel entry (27.0.0.15,239.1.1.106)(downlink-1) del end
Ticket: CM-26732
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
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>
This patch does two things:
1) Ensure the decoding of stream data between pim <-> zebra is properly
decoded and we don't read beyond the end of the stream.
2) In zebra when we are freeing memory alloced ensure that we
actually have memory to delete before we do so.
Ticket: CM-27055
Signed-off-by: Satheesh Kumar K <sathk@cumulusnetworks.com>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Initially, MLAG Sync is happened at pim_ifchannel, this is mainly to
support even config mismatches(missing configuration of dual active).
But this causes more syncs for each entry.
and also it is not In-line with PIM EVPN. to avoid that moving to
pm_upstream based syncing.
Signed-off-by: Satheesh Kumar K <sathk@cumulusnetworks.com>
(S,G) entries that inherit ipmr-lo into the OIL also inherit
the DF role from the parent (*, G) entry.
This change is done primarily to simplify the sync process and
to prevent the MLAG peers from having to track (S, G) activity etc.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
There exists the possibility that a RP exists as a anycast
pair for a lan segment. As such one side may receive
the register and properly handle the registration mechanics.
The one that does not receive the register packets will still
get S,G state and WRVIFWHOLE upcalls across the lan. In
this case notice that we have not received the Registration
packets and prevent nexthop lookups.
Ticket: CM-27466
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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>
When the WRVIFWHOLE callback is made with a iifp of the pimreg
device we *know* that the packet is a PIM Register packet
( see net/ipv4/ipmr.c for kernel behavior ). As such
we know that we will shortly read the pim register packet
and handle it through those mechanics. There is nothing
to do here so we can move along.
Ticket: CM-27729
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Issue 1:
1. Enable pim on an interface.
2. Configure query-interval or query max response time,
which results in pimd crash.
Root cause:
1. When pim is enabled on an interface, it creates a igmp socket
with querier_timer and other_querier time as NULL.
2. When query-interval/max_response_time is configured, it call the
function igmp_sock_query_reschedule() to reshedule the query. This
function check either of querier_timer or other_querier timer should
be running. Since in this case both are NULL, it results in crash.
Issue 2:
1. Enable pim on an interface.
2. Execute no ip igmp query-interval or query max response time,
which results in pimd crash.
Root cause:
1. When pim is enabled on an interface, it creates a pim interface
with querier_timer and other_querier time as NULL.
2. When no ip igmp query-interval/max_response_time is executed, it will
check either of querier_timer or other_querier timer should be running.
Since in this case both are NULL, it results in crash.
Fix:
When pim is enabled on an interface, it creates a igmp socket with
mtrace_only as true. So add a check if mtrace_only is true, then don't
reshedule the query.
Signed-off-by: Sarita Patra <saritap@vmware.com>
Issue:
Client---LHR---RP
1. Add kernel route for RP on LHR. Client send join
2. (*,G) will be get created in LHR and RP.
3. Kill the FRR on all the nodes
4. Start FRR only on LHR node
5. In LHR, (*, G) will be created with iif as unknown.
Root cause:
In the step 4, When LHR will receive igmp join, it will call
the function pim_ecmp_fib_lookup_if_vif_index which will look
for nexthop to RP with neighbor needed as false. So RPF lookup will
be true as the route is present in the kernel. It will create a
(*, G) channel_oil with incoming interface as the RPF interface
towards RP and install the (*,G) mroute in kernel.
Along with this (*,G) upstream gets craeted, which call the function
pim_rpf_update, which will look for the nexthop to RP with neighbor
needed as true. As the frr is not running in RP, no neighbor is present
on the nexthop interface. Due to which this will fail and will update
the channel_oil incoming interface as MAXVIFS(32).
Fix:
pim_ecmp_fib_lookup_if_vif_index() call the function pim_ecmp_nexthop_lookup
with neighbor_needed as true.
Signed-off-by: Sarita Patra <saritap@vmware.com>
Issue: REGISTER-STOP Rx is always displaying 0.
Root-cause: pim_ifstat_reg_stop_recv is not getting
incremented when register stop message is received.
Fix: Increment pim_ifstat_reg_stop_recv on receiving
of pim register stop packet.
Signed-off-by: Sarita Patra <saritap@vmware.com>
It's been a year search and destroy.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
- Add extern modifier to some declarations in header file and move
qpim_all_pim_routers_addr definition to pimd/pimd.c
`GCC now defaults to -fno-common. As a result, global variable accesses
are more efficient on various targets. In C, global variables with
multiple tentative definitions now result in linker errors.`
Taken from https://gcc.gnu.org/gcc-10/changes.html
Signed-off-by: Tomas Korbar <tkorbar@redhat.com>
1. show ip pim mlag summary
provides MLAG session information and stats
2. show ip pim mlag upstream
displays the upstream entries synced across the MLAG switches
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.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>
PIM MLAG DF election API was not being triggered on cost change if the
upstream neighbor remained the same.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
In an anycast VTEP setup the peerlink_rif is added as a static OIF
to the originating mroute (bypassing the pim state machine). This is
needed to ensure both MLAG switches rx a copy of encapsulated BUM flow.
We were not handling link state changes on this static OIF resulting
in the wrong vifi being used in the OIL (because of vifi re-allocation).
This commit re-acts to oper state changes by deleting the OIF on link
down and re-adding it on link up.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
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>
When local member is added the (*, G) entry may already be in a JOINED
state. In that case the OIL is not updated i.e. pim_channel_add_oif is
not happening for ipmr-lo. Because of this the traffic associated with
the multicast vxlan tunnel is pulled down to the VTEP but not terminated
by the kernel.
This change force updates the OIL anytime ipmr-lo is added or removed
as a local member.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
This is not causing functional problems but has become a source
of confusion. DF status is only relevant to multicast tunnel decaps.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
The RPF cost is incremented by 10 if the RPF interface is the peerlink-rif.
This is used to force the MLAG switch with the lowest cost to the RPF
to become the MLAG DF. If a switch has to go via the peerlink-rif to get
to the RP or source it simplly cannot be the designated forwarder.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
DF election is only run for (*,G) entries i.e. election is skipped
for (S,G) entries that are setup as a result of SPT switchover. (S,G)
entries inherit the DF role from the parent (*,G) entry. So the DF is
responsible for terminating all sources associated with a group.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
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>
Channel with the MLAG daemon is setup on the first VxLAN BUM MDT or
pim-mlag AA SVI.
This channel is used for -
1. rxing MLAG status status updates (peer state, role etc.)
2. for syncing active-active upstream entries with the peer MLAG
switch.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
The vrrpd one conflicts with the standalone vrrpd package; also we're
installing daemons to /usr/lib/frr on some systems so they're not on
PATH.
Signed-off-by: David Lamparter <equinox@diac24.net>
Update zclient_lookup_nexthop_once() to create the zapi
header using the vrf_id on the pim->vrf struct.
This is the one we do a check on a couple lines before, so
we should be using it when we actually create the header as
well.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Allow pimd to stop the lookup if zebra tells pimd that the
lookup failed due to a zapi error. Otherwise, it will keep
waiting for a nexthop message that will never come.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
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>
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>
Kernel might not hand us a bad packet, but better safe than sorry here.
Validate the IP header length field. Also adds an additional check that
the packet length is sufficient for an IGMP packet, and a check that we
actually have enough for an ip header at all.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
We check that the IGMP message is sufficently sized for an mtrace query,
but not a response, leading to uninitialized stack read.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Allow 'ip igmp join' to join group for any source if no source is
specified.
Disallow joining source "0.0.0.0" as it is used to define an
any-source multicast group.
Signed-off-by: Liam McBirnie <liam.mcbirnie@boeing.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>
use_rpt macro depends on JoinDesired macro and is mostly independent of the
actual RPF interface i.e. doesn't change when the RPF interface changes.
There is however one exception to this handling and that is on the
first hop router (DR or non-DR). On the DR the FHR flag is set so the
RPF interface stays irrelevant to use_rpt eval. But on the non-DR the
IIF is the only way to know we are directly connected to the SG i.e.
to know that we must NOT switch the source to RPT.
This commit fixes up the order of use_rpt eval -
1. it is done before mroute programming
2. but after IIF setup, for SRC_NOCACHE and STATIC_IIF upstream entries
Note: drop an unnecessary check to verify that the RPF interface is
pim enabled. This is just to make the code consistent.
Ticket: CM-27446
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
A variety of buffer overflow reads and crashes
that could occur if you fed bad info into pim.
1) When type is setup incorrectly we were printing the first 8 bytes
of the pim_parse_addr_source, but the min encoding length is
4 bytes. As such we will read beyond end of buffer.
2) The RP(pim, grp) macro can return a NULL value
Do not automatically assume that we can deref
the data.
3) BSM parsing was not properly sanitizing data input from wire
and we could enter into situations where we would read beyond
the end of the buffer. Prevent this from happening, we are
probably left in a bad way.
4) The received bit length cannot be greater than 32 bits,
refuse to allow it to happen.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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>
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>
When you configure interface configuration without explicitly
configuring pim on that interface, we were not creating the pimreg
interface and as such we would crash in an attempted register
since the pimreg device is non-existent.
The crash is this:
==8823== Invalid read of size 8
==8823== at 0x468614: pim_channel_add_oif (pim_oil.c:392)
==8823== by 0x46D0F1: pim_register_join (pim_register.c:61)
==8823== by 0x449AB3: pim_mroute_msg_nocache (pim_mroute.c:242)
==8823== by 0x449AB3: pim_mroute_msg (pim_mroute.c:661)
==8823== by 0x449AB3: mroute_read (pim_mroute.c:707)
==8823== by 0x4FC0676: thread_call (thread.c:1549)
==8823== by 0x4EF3A2F: frr_run (libfrr.c:1064)
==8823== by 0x40DCB5: main (pim_main.c:162)
==8823== Address 0xc8 is not stack'd, malloc'd or (recently) free'd
pim_register_join calls pim_channel_add_oif with:
pim_channel_add_oif(up->channel_oil, pim->regiface,
PIM_OIF_FLAG_PROTO_PIM);
We just need to make srue pim->regiface exists once we start configuring
pim.
Fixes: #5358
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When configuring a RP, dissallow the choice of 0.0.0.0 or
255.255.255.255 as the address as that they make no sense
what so ever.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
We were adding a newline for the source in some cases
but not others and tighten up the display of data
eva# show ip pim rp-info
RP address group/prefix-list OIF I am RP Source
10.254.0.1 224.0.0.0/4 lo yes Static
4.4.4.4 225.1.2.3/32 abcdefghijklmno yes Static
10.0.20.45 226.200.100.100/32 r1-eth0 no Static
eva#
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
SPT switchover handling is done by adding pimreg in the OIL of the (*, G)
entry on the LHR. This causes multicast data with that destination to be
sent to pimd as IGMPMSG_WHOLEPKT. These packets trigger creation of (S,G)
and also register forwarding. However register forwarding must only be done
if the router is also a FHR. That FHR check was missing causing strange
source registrations from multicast routers that were not directly
connected to the source.
Relevant logs from LHR -
PIM: pim_mroute_msg: pim kernel upcall WHOLEPKT type=3 ip_p=0 from fd=9 for (S,G)=(6.0.0.30,239.1.1.111) on pimreg vifi=0 size=98
PIM: Sending (6.0.0.30,239.1.1.111) Register Packet to 81.0.0.5
PIM: pim_register_send: Sending (6.0.0.30,239.1.1.111) Register Packet to 81.0.0.5 on swp2
And 6.0.0.30 is clearly not directly connected on that router -
root@tor-11:~# ip route |grep 6.0.0.30 -A2
6.0.0.30 proto ospf metric 20
nexthop via 6.0.0.22 dev swp1 weight 1 onlink
nexthop via 6.0.0.23 dev swp2 weight 1 onlink
root@tor-11:~#
Ticket: CM-24549
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
It was causing a Join on (S,G) who's prune state was being cleared. This
was an inactive (KAT not running; no immediate OIL) entry that was being
flushed out but because of this incorrect Join (that was being done with
out join-state checks) the source was getting populated repeatedy i.e.
never aged.
Output of "ip monitor mroute"
=============================
(27.0.0.11,239.1.1.102) Iif: lo State: resolved Table: default
Deleted (27.0.0.11,239.1.1.102) Iif: lo State: resolved Table: default
(27.0.0.11,239.1.1.102) Iif: pimreg State: resolved Table: default
(27.0.0.11,239.1.1.102) Iif: uplink-1 State: resolved Table: default
(27.0.0.11,239.1.1.102) Iif: uplink-1 State: resolved Table: default
(27.0.0.11,239.1.1.102) Iif: uplink-1 State: resolved Table: default
(27.0.0.11,239.1.1.102) Iif: lo Oifs: uplink-1 State: resolved Table: default
(27.0.0.11,239.1.1.104) Iif: lo Oifs: pimreg uplink-1 State: resolved Table: default
(27.0.0.11,239.1.1.102) Iif: lo Oifs: pimreg uplink-1 State: resolved Table: default
Deleted (27.0.0.11,239.1.1.102) Iif: lo State: resolved Table: default
(27.0.0.11,239.1.1.102) Iif: pimreg State: resolved Table: default
(27.0.0.11,239.1.1.102) Iif: uplink-1 State: resolved Table: default
(27.0.0.11,239.1.1.102) Iif: uplink-1 State: resolved Table: default
(27.0.0.11,239.1.1.102) Iif: uplink-1 State: resolved Table: default
(27.0.0.11,239.1.1.102) Iif: lo Oifs: uplink-1 State: resolved Table: default
These mroute events (on a no longer existing multicast souce) continue in
a never ending loop.
Triggered joins/prunes MUST only done via state machine transitions i.e.
via pim_upstream_update_join_desired.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
JD macro is defined by the RFC as -
bool JoinDesired(S,G) {
return (immediate_olist(S,G) != NULL
OR (KeepaliveTimer(S,G) is running
AND inherited_olist(S,G) != NULL))
}
However for MSDP synced SA the KAT will not be running so an exception is
needed. Earlier I had done this by relaxing KAT_run requirements entirely
on the RP. However as that prevents the source from being aged out in some
cases I have made the check more narrow i.e. has to an MSDP peer added
entry.
Ticket: CM-24398
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
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>
Today we are only pruning the SPT when (S,G) upstream entry
switches from Joined toNotJoined. This leaves the source still
pruned along the RPT till the next periodic XG join-prune is sent
to the RPF(RP). Traffic from the source will be blackholed for this
duration. To prevent that we need send a new JP message
to RPF(RP) immediately.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
It is now used to evaluate and display join-desired state for
each upstream entry -
root@spine-1:~# net show pim upstream-join-desired
Source Group EvalJD
* 239.1.1.111 yes
6.0.0.28 239.1.1.111 yes
6.0.0.29 239.1.1.111 no
6.0.0.30 239.1.1.111 yes
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
This re-naming was needed because the JD state on an upstream is
not just based on channel info i.e. we can have JD=true even if there
is no downstream channel. The "show ip upstream-join-desired" command
will be changed to display that info i.e. upstream's JD state instead
of downstream channel params. The downstream channel params are now
available via "show ip pim channel"
PS: This change maybe reverted if upstream NAKs it. But there is a
pressing need for it to debug some not-so-reproduible problems.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
This was causing pimd to crash later; call-stack -
(gdb) bt
context=<optimized out>) at lib/sigevent.c:254
group=group@entry=0x7ffffa9797e0) at pimd/pim_rp.c:207
grp=grp@entry=0x7ffffa9799fe, sgs=sgs@entry=0x560ac069edb0, size=52)
at pimd/pim_msg.c:200
groups=<optimized out>) at pimd/pim_join.c:562
at pimd/pim_neighbor.c:288
at lib/thread.c:1599
at lib/libfrr.c:1024
envp=<optimized out>) at pimd/pim_main.c:162
(gdb) fr 4
group=group@entry=0x7ffffa9797e0) at pimd/pim_rp.c:207
207 pimd/pim_rp.c: No such file or directory.
(gdb) fr 6
grp=grp@entry=0x7ffffa9799fe, sgs=sgs@entry=0x560ac069edb0, size=52)
at pimd/pim_msg.c:200
200 pimd/pim_msg.c: No such file or directory.
(gdb) p source->up->sg_str
$1 = '\000' <repeats 31 times>, <incomplete sequence \361>
(gdb)
This problem can manifest in the following event sequence -
1. upstream RPF neighbor is resolved
2. upstream RPF neighbor becomes unresolved (but upstream entry
stays on the jp-agg list)
3. upstream entry is removed
on the next old-neighbor jp-agg-list processing the stale entry is
accessed resulting in the crash.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Dumps while in problem state -
============================
[from "show ip pim state"]
Active Source Group RPT IIF OIL
1 6.0.0.31 239.1.1.111 n swp1 swp4( J * )
[from "show ip pim join"]
Interface Address Source Group State Uptime Expire Prune
swp3 6.0.0.22 6.0.0.31 239.1.1.111 JOIN --:--:-- 03:11 --:--
You can see from the dumps that the pim downstream router has joined on
swp3 but that OIF has not been added to the OIL with flag
PIM_OIF_FLAG_PROTO_PIM. This is because the join was rxed while the
ifchannel was in a prune-pending state.
Relevant logs -
===============
[
PIM: recv_prune: prune (S,G)=(6.0.0.31,239.1.1.111) rpt=1 wc=0 upstream=6.0.0.22 holdtime=210 from 6.0.0.28 on swp3
PIM: pim_upstream_ref(pim_ifchannel_add): upstream (6.0.0.31,239.1.1.111) ref count 3 increment
PIM: pim_upstream_add(pim_ifchannel_add): (6.0.0.31,239.1.1.111), iif 6.0.0.26/0 (swp1) found: 1: ref_count: 3
PIM: pim_ifchannel_add: ifchannel (6.0.0.31,239.1.1.111) is created
PIM: pim_joinprune_recv: SGRpt flag is set, del inherit oif from up (6.0.0.31,239.1.1.111)
PIM: pim_mroute_add(pim_channel_del_oif), vrf default Added Route: (6.0.0.31,239.1.1.111) IIF: swp1, OIFS: swp4
PIM: pim_channel_del_oif(pim_joinprune_recv): (S,G)=(6.0.0.31,239.1.1.111): proto_mask=4 IIF:1 OIF=swp3 vif_index=3
PIM: recv_join: join (S,G)=(6.0.0.31,239.1.1.111) rpt=0 wc=0 upstream=6.0.0.22 holdtime=210 from 6.0.0.28 on swp3
PIM: PIM_IFCHANNEL(swp3): (6.0.0.31,239.1.1.111) is switching from SGRpt(PP) to JOIN
PIM: Sending Request for New Channel Oil Information(6.0.0.31,239.1.1.111) VIIF 1(default)
]
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
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>
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>
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>
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>
A dummy pim upstream entry can be in a JOINED state before its RPF nbr is
added. Handle that case by triggering an immediate join.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Deviations -
1. Avoid using SPTbit setting. Replace that with Use_Spt macro.
2. If S is supposed to be forwarded along the RPT but has an empty OIL
prune it.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
1. KAT should be re-started only if traffic rxed along the SPT i.e.
IIF == RPF_Interface(S).
Only exception to the rule is if you are LHR.
2. KAT should be started on all routers (not just FHR, RP, LHR).
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Criteria for switching to SPT is different on RP and LHR. Re-name
the functions to make that apparent.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Joined state is computed based on the downstream state and cannot be
changed if the RPF link flaps.
Reference: rfc 7761, section 4.5.5
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
This commit includes the following changes -
1. kat needs to be included when evaluting join desired on a (S,G)
entry.
2. there were cases where we were adding OIF based on joindesired
being true for unrelated reasons (on other OIFs). cleaned up those
cases.
3. make all calls to pim_upstream_switch conditional on the JoinDesired
macro.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
RP config change is a big hammer and use_rpt/spt needs to be
re-evaluated on all existing (S,G) entries.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
If a source is being forwarded along the RPT it uses the parent (*,G)'s
IIF. When the parent's IIF changes all the children need to be updated
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
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>
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>
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>
1. This avoids the needs to re-run "muting" decisions.
2. Avoids the need to restore's pim OIL after fixup and send to kernel
(this is getting harder to manage).
In the future we need to also move the PIM maintained channel OIL from
an array of MAXVIFs to a simple DLL. This will be a significant
optimization in memory usage and preformance (OIL reads, copies etc).
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
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>
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>
1. add the Mlag ProtoBuf Lib to Zebra Compilation
2. Encode the messages with protobuf before writing to MLAG
3. Decode the MLAG Messages using protobuf and write to clients
based on their subscrption.
Signed-off-by: Satheesh Kumar K <sathk@cumulusnetworks.com>
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>
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>
When receiving igmp packets we are spitting out a lot of
debugs. Attempt to clean this up to allow us to understand
what is going on a bit better by just being able to look
at the log file.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When you turn on `debug igmp trace` we are seeing a bunch
of debugs associated with pim processing. This is because we were
using PIM_DEBUG_TRACE which is both `debug igmp trace` and `debug pim trace`
when tracing igmp code it would be nice to only see igmp work.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
We are seeing situations where PIM is sending a IGMP v3 query
and immediately receiving back up the pim kernel interface the
query from itself:
from `show int brief`:
swp7 up default 192.168.202.1/24
We are also receiving these debugs:
2019-11-11T20:52:40.452307+00:00 leaf02 pimd[1592]: Send IGMPv3 query to 224.4.0.8 on swp7 for group 224.4.0.8, sources=0 msg_size=12 s_flag=0 QRV=2 QQI=125 QQIC=7d
2019-11-11T20:52:40.452430+00:00 leaf02 pimd[1592]: pim_mroute_msg(default): igmp kernel upcall on swp7(0x55eaa7dc7dc0) for 192.168.202.1 -> 224.4.11.123
2019-11-11T20:52:40.452574+00:00 leaf02 pimd[1592]: Recv IP packet from 192.168.202.1 to 224.4.11.123 on swp7: size=40 ip_header_size=24 ip_proto=2
2019-11-11T20:52:40.452699+00:00 leaf02 pimd[1592]: Recv IGMP packet from 192.168.202.1 to 224.4.11.123 on swp7: ttl=1 msg_type=17 msg_size=16
2019-11-11T20:52:40.452824+00:00 leaf02 pimd[1592]: Recv IGMP query v3 from 192.168.202.1 on swp7 for group 224.4.11.123
This query is causing us to do some weird gyrations around the IGMP state machine for handling
queries. Let's just prevent it from happening.
Ticket: CM-27247
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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>
We have a zlog_warn that is unguarded ( and really is a debug message )
as that there is nothing the end user can do and nothing to note
here other than a debug message to track refcounts. Change
to an appropriate debug and zlog_debug it instead.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When you enter:
ip pim ssm prefix-list my-custom-ssm-range
ip pim ssm prefix-list my-custom-ssm-range
The second instance would cause a failure to happen which
should not happen w/ duplicate config.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Scenarios where this code change is required:
1. BFD is un-configured from BGP at remote end.
Neighbour BFD sends ADMIN_DOWN state, but BFD on local side will send
DOWN to BGP, resulting in BGP session DOWN.
Removing BFD session administratively shouldn't bring DOWN BGP session
at local or remote.
2. BFD is un-configured from BGP or shutdown locally.
BFD will send state DOWN to BGP resulting in BGP session DOWN.
(This is akin to saying do not use BFD for BGP)
Removing BFD session administratively shouldn't bring DOWN BGP session at
local or remote.
Signed-off-by: Sayed Mohd Saquib sayed.saquib@broadcom.com
The result variable was already tested against PIM_GROUP_BAD_ADDR_MASK_COMBO
earlier in the function. No need to do the same thing twice.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
All paths leading to this point in the code have already deref'ed
the pim->global_scope.bsrp_table. No point in testing for
validness now. This was caught by Coverity.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The pim_msg_send() return code was not being checked. Make
consistent with it's usage everywhere else.
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>
There are several places in the pim where we are mixing up
zlog_warn w/ zlog_debug and vice versa. If we are protecting
a zlog_warn w/ a debug is it really a warn? If we have an actual
error situation we should also warn about it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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>
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>
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>
The Pim RFC does not appear to state any length requirements
of pim, other than the checksum must be correct.
Certain vendors are sending extra data at the end of a pim assert
message. This while not explicitly against the rules was a bit
of surprise to pim when we threw the assert message on the floor
for being too long.
Modify the test to see if length left will allow us to read
the 8 bytes of data that we need. If it is sufficient for
that allow the packet to be used.
Fixes: #4957
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Original Idea is to display normal & detailed debugs when detailed
debug alone is configured. because of this "sh debugs" are showing
wrong Information, because same macro is used to disply the configured
debugs.
that means even if Normal debug is configured, detailed macro returns
TRUE. To avoid this ambiguity check whetehr detailed debug is configured
or not during dumping configured debugs. In all other places using
old macro.
Signed-off-by: Satheesh Kumar K <sathk@cumulusnetworks.com>
Debian packaging when run finds a bunch of spelling errors:
I: frr: spelling-error-in-binary usr/bin/vtysh occurences occurrences
I: frr: spelling-error-in-binary usr/lib/frr/bfdd Amount of times Number of times
I: frr: spelling-error-in-binary usr/lib/frr/bgpd occurences occurrences
I: frr: spelling-error-in-binary usr/lib/frr/bgpd recieved received
I: frr: spelling-error-in-binary usr/lib/frr/isisd betweeen between
I: frr: spelling-error-in-binary usr/lib/frr/ospf6d Infomation Information
I: frr: spelling-error-in-binary usr/lib/frr/ospfd missmatch mismatch
I: frr: spelling-error-in-binary usr/lib/frr/pimd bootsrap bootstrap
I: frr: spelling-error-in-binary usr/lib/frr/pimd Unknwon Unknown
I: frr: spelling-error-in-binary usr/lib/frr/zebra Requsted Requested
I: frr: spelling-error-in-binary usr/lib/frr/zebra uknown unknown
I: frr: spelling-error-in-binary usr/lib/x86_64-linux-gnu/frr/libfrr.so.0.0.0 overriden overridden
This commit fixes all of them except the bgp `recieved` issue due to
it being part of json output. That one will need to go through
a deprecation cycle.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Pim will do the nexthop registration with "ip pim rp" static configuration
with this Zebra will advertise the Route Information.
But while processing this info at PIM, if Nexthop Interfaces are not PIM
enabled, currently PIM is dropping those paths. in case all paths are not
PIM enabled, there is no valid RPF Interface at PIM.
and PIM will be stuck at this state until Next update this to route, that
can happen only if there is a Routing change at Zebra for this prefix.
until that time PIM will not have any valid outgoing Interface.
This issue was mainly seen during Node bootup scenarios.
Fix Proposed
=============
store the paths in PIM PNC Data structure though they are not enabled
with PIM, because while selecting the Interface PIM checks for multicast
enabled Interface.
Tests Performed
===============
1. Verified fail Test case
2. Disabling the PIM on selected outgoing Interface, PIM is choosing
another path when Neighbor is down on this Interface.
3. Re-configure the PIM on above un-configured Interface, PIM is staying
with old NHop since it is valid.
Signed-off-by: Satheesh Kumar K <sathk@cumulusnetworks.com>
Modify the code to create an upstream reference whenever the code
creates an channel_oil via the pim_mroute.c code. This code also
starts a keep alive timer to clean up the reference if we do
nothing with it after the normal time.
I've left alone the source->channel_oil creation because these
are kept and tracked independently already.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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>
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>
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>
When we receive an igmp query on a interface, ensure that the
source address of the packet is connected to the incoming
interface. This will prevent a meanie from crafting a igmp
packet with a source address less than ours and causing
us to suspend query activities.
Fixes: #1692
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Fix details :
Added a utility cli to generate a igmp query on an interface.
This won't impact the existing query generation based on the
general query interval.
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
In a pim-evpn setup (say TORC11<=>TORC12) an mroute can have a mix of
PIM and IGMP joins. The vxlan termination device ipmr-lo is IGMP
joined on termination mroutes and the peerlink-rif can be pim joined
on the same mroute if the MLAG peer (TORC11) loses all its uplinks to
underlay -
root@TORC12:~# net show pim state 239.1.1.101|grep pimreg
1 * 239.1.1.101 uplink-1
pimreg(I ), ipmr-lo( J ), peerlink-3.4094( J )
root@TORC12:~#
When the uplinks come back up on TORC11 it will prune the peerlink-rif
and join the RP (say spine) via the uplinks.
TORC12 is rxing the prune and removing the if_channel
(pim_ifchannel_delete). However it is not removing the OIF from
mfcc_ttl basically leaving behind a leaked OIF in the forwarding
entry. And this is because it is deriving the owner flag from the
parent upstream entry and incorrectly concluding that all OIFs are
IGMP joined.
Thix fix flushes out both PIM and IGMP ownership when the ifchannel is
deleted.
There is a second fix in the commit and that is to set the proto mask
correctly (to STAR) for inherited OIFs. (S,G) entries can inherit the
OIF from the (*, G) entry and this decision can change when the pim/igmp
ifchannel is removed. The earlier code was setting the proto-mask
incorrectly to PIM or IGMP.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
(cherry picked from commit d4d1d968dbbe61347393f7dace8b675496ff1024)
When a link goes down the vifi was being deleted but the OIF stayed
in the OIL with a stale vifi -
oroot@act-7726-03:~# net show pim state
Codes: J -> Pim Join, I -> IGMP Report, S -> Source, * -> Inherited from (*,G), V -> VxLAN
Installed Source Group IIF OIL
1 * 239.1.1.111 swp1s1 pimreg(I ), ipmr-lo( J )
1 6.0.0.28 239.1.1.111 lo pimreg( J ), ipmr-lo( *), swp1s1( J )
root@act-7726-03:~# ip link set swp1s1 down
root@act-7726-03:~# net show pim state
Codes: J -> Pim Join, I -> IGMP Report, S -> Source, * -> Inherited from (*,G), V -> VxLAN
Installed Source Group IIF OIL
1 * 239.1.1.111 swp1s0 pimreg(I ), ipmr-lo( J )
1 6.0.0.28 239.1.1.111 lo ipmr-lo( *), swp1s0( J ), <oif?>( J ) >>>>>>>>
root@act-7726-03:~#
The problem was as a part ifchannel_delete the join state of the channel
was checked to avoid incorrect OIF deletion this was preventing the OIF
from being flushed. Fix is to flip the channel join-state to NOINFO before
deleting it.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
There has never been a `debug igmp trace detail` but we have
had code to display this when we had the appropriate flags
set. Since we never can accept this, let's remove this.
This showed up because of commit:0ab16492d2d9fcc6cba7e001227deed6765ed261
where we re-arranged some debugs to combine them being turned on.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Position of address family and encoding type is defined wrongly in the
packed structure. This will correct the position as per RFC 4601 4.9.1
Signed-off-by: Saravanan K <saravanank@vmware.com>
If we create a channel_oil ensure that all paths that
we can go down will create one. Future commits
can remove the (up->channel_oil) tests.
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>
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>
This is mostly relevant for Solaris, where config.h sets up some #define
that affect overall header behaviour, so it needs to be before anything
else.
Signed-off-by: David Lamparter <equinox@diac24.net>
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>
clippy can't process #ifdef or similar bits inside of an argument list
(e.g. within the braces of a DEFUN or DEFPY statement.) Improve error
reporting to catch these cases instead of generating broken C code.
Fixes: #3840
Signed-off-by: David Lamparter <equinox@diac24.net>
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>
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>
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>
The pim ifchannel expiry timer was not setting any debug output.
Let's add something in to help us understand what is going on.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
We already log whether or not we add nht tracking, having
an additional boolean to say to log another line is
a bit over the top.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
While this is impossible, make the compilers a bit happier
for those of us having to use something old.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com
Various compilers in our CI system were complaining about various
auto-conversions. Let's get these cleaned up a bit more.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When pim is started and has nothing to talk to zebra about
over the zlookup socket and interface events are happening
then the zlookup socket is not being drained.
This eventually leads to a situation where the kernel send buffer
fills up and zebra is unable to write anything down the pipe.
At this time the zapi starts buffering data in `struct buffer`
which of course slowly fills up as pim has nothing to do.
As a bit of a hack allow the zlookup socket to wake up 1 time
a minute and ask for information about the default route
and do nothing with it. This will cause the socket buffers
to be drained and the system will be happy.
Long term we need to get rid of this synchronous/asynchronous
duality that pim has. This is on the radar but is not something
that could be fixed in an afternoon or a week of effort in my
opinion. Given time constraints right now. Let's put this
in place and then once we get pim completely async then
we can just remove the zlookup( I hope ) code.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
A couple of places of strncpy snuck in due to my confusion
about if Quentin's earlier change had gotten in. Just some
code in flux. This should fix the issue/warnings in our
CI system.
Recent commits rewrote the `clear mroute` command and this caused
these two two functions to no longer be used, remove.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The header inclusion in mtracebis.c should include zebra.h
and not config.h. There are other issues that need to
be worked through as well, but we can do this in the future.
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>
Introduced a new command "show ip mroute summary"
to display total number of (*, G) and (S, G) mroutes
created and number of mroutes installed in the kernel.
Signed-off-by: Sarita Patra <saritap@vmware.com>
Made changes to clean up the all upstreams and ifchannels
in FRR apart from cleanup datapath mroutes when this command
issued.
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
Fix: When RP receives a (*, G) join and corresponding (s,g)
is present, then check for OIL is not-empty, then only switch
upstream (s, g) state to JOINED.
Signed-off-by: Sarita Patra <saritap@vmware.com>
This would show only bsm related statistics for now.
We shall add more statistics to this later.
Sw3# show ip pim statistics
BSM Statistics :
----------------
Number of Received BSMs : 1584
Number of Forwared BSMs : 793
Number of Dropped BSMs : 1320
Interface : ens192
-------------------
Number of BSMs dropped due to config miss : 0
Number of unicast BSMs dropped : 0
Number of BSMs dropped due to invalid scope zone : 0
Interface : ens224
-------------------
Number of BSMs dropped due to config miss : 0
Number of unicast BSMs dropped : 0
Number of BSMs dropped due to invalid scope zone : 0
Interface : ens256
-------------------
Number of BSMs dropped due to config miss : 0
Number of unicast BSMs dropped : 0
Number of BSMs dropped due to invalid scope zone : 0
Signed-off-by: Saravanan K <saravanank@vmware.com>
This command shows all the fragments of the last received preferred BSM.
This displayed in readable format.
Sw3# sh ip pim bsm-database
Scope Zone: Global
Number of the fragments: 1
BSM Fragment : 1
------------------
BSR-Address BSR-Priority Hashmask-len Fragment-Tag
30.0.0.100 0 0 3289
Group : 225.1.1.1/32
-------------------
Rp Count:9
Fragment Rp Count : 9
RpAddress HoldTime Priority
20.0.0.2 150 0
2.2.2.2 150 0
9.9.9.10 150 0
7.7.2.7 150 0
7.2.2.7 150 0
7.7.9.7 150 0
7.8.9.10 150 0
7.5.2.7 150 0
9.10.9.10 150 0
Group : 226.1.1.1/32
-------------------
Rp Count:1
Fragment Rp Count : 1
RpAddress HoldTime Priority
9.9.9.9 150 0
Signed-off-by: Saravanan K <saravanank@vmware.com>
If no_fwd bit not set,
forward on all interfaces including which it came.
store it in bsm list with size for forwarding it later to new neighbor.
calculate PIM mtu of the interface, if bsm size is more do sematic frag and send
Signed-off-by: Saravanan K <saravanank@vmware.com>
When all rp received on a partial list, this routine is called.
if static rp configured for the group range
if partial list is empty
clean main list and partial list
else
replace main with partial and start the g2rp timer with head of new main
return
if main list was empty
call rp new with head of partial list and start g2rp timer.
else
if partial list is empty
call rp del
else
stop g2rp timer of old elected rp.
call rp change with new rp(head of partial list) and start g2rp timer.
swap the lists and clean the old list(now partial list).
Signed-off-by: Saravanan K <saravanank@vmware.com>
Bootstrap rp table is route_table datastructure with group range as key.
Each node represents a group range.
Every node has two lists of rp nodes. partial list and active list(bsrp_list)
Whenever a rp is parsed from BSM, it is updated to partial list.
When partial list is full, we move it to main list(bsrp_list). This commit doesn't cover that.
Rp Election routine based on RFC 7761 Sec 4.7
Hash calculation for rp election based on RFC 7761 Sec 4.7.2
Signed-off-by: Saravanan K <saravanank@vmware.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>
When bs time out occurs,
1. Delete the bsm list
2. Reset the BSR address
3. delete nexthop tracking for the expired BSR
4. Give one more lease of life to all the bsr advertised rp with hold time
5. clear partial list of each grp node if not empty
Signed-off-by: Saravanan K <saravanank@vmware.com>
DS Overview:
Bootstrap RP table has grp node.
scope --> rp table --> grp node1 --> rp list --> rp nodes(g2rp timer)
|
-------> grp node2 --> rp list --> rp nodes(g2rp timer)
When grp2rp mapping expires, following has to be done.
1. delete the rp node from the active bs-rp list in the list
2. calculate the elapsed time for other rp nodes in the list
3. delete those nodes having more elapse time than their hold time
4. If the list is not empty and current rp src is not static
rp change with new rp(head) & start g2rp timer with value holdtime - elapse
5. If the list is empty and current rp src for the grp is not static
delete the rp
6. If the list is not empty and current rp is static, just start the
g2rp timer with value holdtime - elapse
7. If list is empty and pending list is empty, delete grp node.
Note: g2rp timer will be run only on elected RP node for optimization.
when it expires, other node are update with elapse time.
This list is sorted insuch way that elected RP is the HEAD of list
Signed-off-by: Saravanan K <saravanank@vmware.com>
Command to display current bsr, last received bsm ts, bsr uptime
Sw3# sh ip pim bsr
PIMv2 Bootstrap information
Current preferred BSR address: 30.0.0.100
Priority Fragment-Tag State UpTime
0 6390 ACCEPT_PREFERRED 91:26:24
Last BSM seen: 00:00:37
Signed-off-by: Saravanan K <saravanank@vmware.com>
pim_rp_new split into pim_rp_new_config and pim_rp_new.
pim_rp_new_config is called by CLI.
pim_rp_new will be called by pim_rp_new_config and bsm rp config.
pim_rp_del is split into pim_rp_del_config and pim_rp_del
pim_rp_del_config is called by CLI.
pim_rp_del is called by pim_rp_del_config and bsm rp config
Signed-off-by: Saravanan K <saravanank@vmware.com>
(intf)ip pim bsm - to enable bsm processing on the interface
(intf)no ip pim bsm - to disable bsm processing on the interface
(intf)ip pim unicast-bsm - to enable ucast bsm processing on the interface
(intf)no ip pim unicast-bsm - to disable ucast bsm processing on the interface
Note: bsm processing and ucast bsm processing is enabled by default on a
pim interface. The CLI is implemented as a security feature as recommended by
RFC 5059
Signed-off-by: Saravanan K <saravanank@vmware.com>
Sw3# sh ip pim rp-info
RP address group/prefix-list OIF I am RP Source
20.0.0.2 225.1.1.1/32 ens192 no BSR
9.9.9.9 226.1.1.1/32 (Unknown) no BSR
30.0.0.100 229.1.1.5/32 ens192 no Static
Signed-off-by: Saravanan K <saravanank@vmware.com>
For each BSM packet, rpf check is performed. We will be accepting if the
source address match any of the next hop neighbor(in ecmp case) to reach
the Bootstrap Router.
1. pim_nexthop_match - this lookup in zebra and return true if any of the
next hop nbr is matching (in ecmp case).
2. pim_nexthop_match_nht_cache - this api searches the given address in local
pnc and return true if any of the next hop
nbr is matching (in ecmp case).
Signed-off-by: Saravanan K <saravanank@vmware.com>
Apart from datastructure, bsm scope initialization and deinitialiation
routines called during pim instance init and deinit. Also makefile changes.
Signed-off-by: Saravanan K <saravanank@vmware.com>
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>
bfd cbit is a value carried out in bfd messages, that permit to keep or
not, the independence between control plane and dataplane. In other
words, while most of the cases plan to flush entries, when bfd goes
down, there are some cases where that bfd event should be ignored. this
is the case with non stop forwarding mechanisms where entries may be
kept. this is the case for BGP, when graceful restart capability is
used. If BFD event down happens, and bgp is in graceful restart mode, it
is wished to ignore the BFD event while waiting for the remote router to
restart.
The changes take into account the following:
- add a config flag across zebra layer so that daemon can set or not the
cbit capability.
- ability for daemons to read the remote bfd capability associated to a bfd
notification.
- in bfdd, according to the value, the cbit value is set
- in bfdd, the received value is retrived and stored in the bfd session
context.
- by default, the local cbit announced to remote is set to 1 while
preservation of the local path is not set.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The route_map_event_hook callback was passing the `route_map_event_t`
to each individual interested party. No-one is ever using this data
so let's cut to the chase a bit and remove the pass through of data.
This is considered ok in that the routemap.c code came this way
originally and after 15+ years no-one is using this functionality.
Nor do I see any `easy` way to do anything useful with this data.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
become stale entries.
Topology:
--------
Source
|
FHR
|
RP ------ LHR --- Recv1
|
Recv2
Root case :
-----------
When RP acts as a LHR i.e RP has a local receiver and registed for
the same group where LHR connected receiver also registered for the
same multicast group.When RP receives a (s,g) join form LHR , it
increments upstream ref count to two to track the Local membership
as well.But at the time of KAT expiry in RP , upstream reference
is not being removed Which is added to track local membership which
is causing to make these entries as stale in RP and FHR.
Fix : Made the change such that it removes the upstream reference
if it is added to track the local memberships.
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
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>
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>
There exists a possiblity that we have upstream data but
at this point in time the rpf failed because there is no
path. As such the rpf interface will be NULL and we
should not necessarily trust it. Prevent a crash
Ticket: CM-24857
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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>
the json code has not been updated since a variety of new flags have
been added to the code base. Add those flags in so we can tell
what is going on sometimes.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add the ability to select on a S or G for a `show ip mroute`
command.
show ip mroute 225.1.1.111
show ip mroute 4.5.6.7 225.1.1.111
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Always when creating a new S,G state look at all possible ifchannels
to decide what the mroute should be.
The bug that this is fixing is this:
Suppose two incoming `*,G` joins on swp1, and swp2.
Now suppose that one of those ifchannel `*,G` sends a `*,G S,G RPT Prune`.
We were creating the S,G upstream state as we should but we were
only looking at the S,G ifchannel to decide the S,G mroute we would
be creating. As such what we need to do is to look over the associated
*,G ifchannels and allow us to associate correct oil needed.
Ticket: CM-24732
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
1. vxlan instance cleanup needs to be done before the upstream entries are
force-flushed.
2. also vxlan callbacks need to be ignored post instance-cleanup.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
This was resulting in static analyzer warnings for subsequent usage
of the same pointer -
pimd/pim_vxlan.c:962:36: warning: Access to field 'info' results in a
dereference of a null pointer (loaded from variable 'ifp')
pim_ifp = (struct pim_interface *)ifp->info;
^~~~~~~~~
1 warning generated.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
The MLAG component on the switch is expected to provide some
properties (such as peerlink-rif) to bootstrap the anycast-VTEP
functionality. The final interface for this is being defined as
a part of the pim-mlag functionality.
This commit provides a hidden command to test the anycast-VTEP
functionality independent of the MLAG component.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Sample output:
root@TORS1:~# vtysh -c "show ip pim vxlan-groups"
Codes: I -> installed
Source Group Input Output Flags
27.0.0.7 239.1.1.101 lo I
* 239.1.1.100 - ipmr-lo I
* 239.1.1.101 - ipmr-lo I
27.0.0.7 239.1.1.100 lo I
root@TORS1:~#
root@TORS1:~# vtysh -c "show ip pim vxlan-work"
Codes: I -> installed
Source Group Input Flags
27.0.0.7 239.1.1.100 lo I
PS: note the worklist dump is a hidden command
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
The unique physical IP is used as the SIP in the ip header to ensure
that pim-register-stop makes it back to the right MLAG switch.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
1. peerlink-rif as OIF in origination mroutes -
Hosts are multi-homed to the anycast-VTEP pair and can send BUM traffic to
either switch. But the RP would have only joined one MLAG switch for
pulling down the MDT. To make that work we add the peerlink/ISL as
an OIF to origination mroutes (TORC11<=>TORC12 is an anycast VTEP pair) -
root@TORC11:~# ip mr |grep "(36.0.0.9, 239.1.1.100)"
(36.0.0.9, 239.1.1.100) Iif: peerlink-3.4094 Oifs: peerlink-3.4094 uplink-1
root@TORC11:~#
root@TORC12:~# ip mr |grep "(36.0.0.9, 239.1.1.100)"
(36.0.0.9, 239.1.1.100) Iif: peerlink-3.4094 Oifs: peerlink-3.4094
root@TORC12:~#
2. VTEP-PIP as register source -
TORC11 and TORC12 share the same anycast VTEP IP (36.0.0.9 in the above
example). And that is the source registered by both VTEPs for all the BUM
mcast-groups. However to allow the pim register start machine to close
the SIP in the register-pkt's IP header must be set to an unique IP address.
This is the VTEP PIP.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
1. special handling of term device in orig mroutes -
The multicast-vxlan termination device ipmr-lo is added to the (*, G)
mroute -
(0.0.0.0, 239.1.1.100) Iif: uplink-1 Oifs: uplink-1 ipmr-lo
This means that it will be inherited into all the SG entries including the
origination mroute. However we cannot terminate the traffic we originate
so some special handling is needed to exclude the termination device
in the origination entries -
27.0.0.7, 239.1.1.100) Iif: lo Oifs: uplink-1
2. special handling of term device on the MLAG pair -
Both MLAG switches pull down BUM-MDT traffic but only one (the DF) can
terminate the traffic. The non-DF must not exclude the termination device
from the MFC to prevent dups to the overlay.
DF -
root@TORC11:~# ip mr |grep "(0.0.0.0, 239.1.1.100)"
(0.0.0.0, 239.1.1.100) Iif: uplink-1 Oifs: uplink-1 ipmr-lo State: resolved
root@TORC11:~#
non-DF -
root@TORC12:~# ip mr |grep "(0.0.0.0, 239.1.1.100)"
(0.0.0.0, 239.1.1.100) Iif: uplink-1 Oifs: uplink-1 State: resolved
root@TORC12:~#
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
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>
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>
To terminate a multicast VxLAN tunnel entry we setup a mroute with
ipmr-lo in the OIL -
(0.0.0.0, 239.1.1.100) Iif: uplink-1 Oifs: uplink-1 ipmr-lo
This is done by the vxlan component that add ipmr-lo as a local
member to termination SG entries. In addition termination entries
are also subject to MLAG DF election on the anycast VxLAN-AA setup.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Two flags have been introduced per-upstream entry -
1. XXX_MLAG_VXLAN - This indicates that MLAG DF (designated-forwarded)
election is needed on the entry. In the case of pim-evpn this flag is set
for termination (*, G) entries and will be inherited by the (S, G) entries
that are created as a result of SPT switchover on the G.
2. XXX_MLAG_NON_DF - This is set on entries that have lost the
DF election. Such entries are primarily used for blackholing traffic on
one of the MLAG switches. On a hardware accelerated switch this blackholing
happens in the ASIC preventing (non-needed) traffic hitting the CPU.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
For multicast vxlan tunnels we register the local VTEP-IP independent
of the prescence of BUM traffic i.e. we prime the pump. This
is acheived via NULL registers.
VxLAN orig entries with upstream in a PIM_REG_JOIN state are linked to
a work list for periodic NULL register transmission. Once the SPT setup
is complete the upstream-entry moves to a PIM_REG_PRUNE state and is
remved from the VxLAN work list.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
In a PIM MLAG setup (say L11<->L12 is the anycast VTEP pair) the RP
can choose to join either MLAG switch as the anycast VTEP-IP is
present on both. Let's say the RP joins L11.
Hosts are dual connected to L11<->L12 and can send traffic to either
switch. Let's say a host sends broadcast traffic to L12; now L12
must encapsulate and send the traffic toward L11. To do that the
origination-mroute on L12 must include the ISL in its OIL -
(36.0.0.9, 239.1.1.100) Iif: peerlink-3.4094 Oifs: peerlink-3.4094
L11 has a similar mroute -
(36.0.0.9, 239.1.1.100) Iif: peerlink-3.4094 Oifs: peerlink-3.4094 uplink-1
This mroute is used to rx traffic on peerlink-3.4094 and send it out of
uplink-1. Note that this mroute also includes the peerlink-rif in its
OIL. Explicit removal of IIF from OIL is done by the kernel (and other
dataplanes) to prevent traffic looping.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
For every (local-vtep-ip, bum-mcast-grp) registered by evpn an origination
mroute is setup by pimd. The purpose of this mroute is to forward vxlan
encapsulated BUM -
Sample mroute (single VTEP):
(27.0.0.7, 239.1.1.100) Iif: lo Oifs: uplink-1
Sample mroute (anycast VTEP):
(36.0.0.9, 239.1.1.100) Iif: peerlink-3.4094\
Oifs: peerlink-3.4094 uplink-1
This commit is part-1 of orignation mroute setup and includes setup
of upstream entries with vxlan properties.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pim-vxlan work is maintained in a lists and processing staggered. One
such work is the generation of periodic null registers for the local
VTEP-IP.
This info is instance agnostic and maintained in a global cache.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
This information will come in from a MLAG component. Hidden commands
will also be provided for testing the interface independent of the
separate MLAG component.
PS: It is possible that this cache will be merged with the base
pim-mlag datastructures once they are available.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pim vxlan component will create upstream entries and OIFs for
multicast VxLAN tunnel origination and termination in single-VTEP
and anycast-VTEP (MLAG) setups.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pim_vxlan will use this for registering the local-VTEP-IP wth the RP
independent of the presence of BUM traffic.
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>
In an anycast VTEP setup the peerlink-rif (ISL) is added as a OIF to the
tunnel origination mroute. A new OIF protocol, VxLAN, has been added to
allow that functionalty.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
