| Age | Commit message (Collapse) | Author |
|---|
|
Topology:
TOR11 (FHR) --- LEAF-11---SPINE1 (RP)MSDP SPINE-2(RP)MSDP --- LEAF-12 -- TOR12 (LHR)
| | | | |
| -----------------------------------------------------(ECMP) |
| | | |
-----------------------------------------------------------------------(ECMP)
Issue:
In some triggers, S,G upstream is preserved even with the PP timer expiry, resulting
in S,G with NULL OILS. This could be because we create a dummy S,G upstream and
dummy channel_oif for *,G, where RPF is UNKNOWN. As a result, PIM+VXLAN traffic is never
forwarded downstream to LHR.
Fix:
when the S,G stream is running, Determine if a reevaluation of the outgoing interface
list (OIL) is required. S,G upstream should then inherit the OIL from *,G.
Testing:
- Evpn pim tests - TestEvpnPimSingleVtepOneMdt.test_02_broadcast_traffic_spt_zero
- pim-smoke
Ticket: #
Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
(cherry picked from commit 071d43a052e04de52771b2f03461c407f0ced36f)
|
|
Whether due to a pimd bug, some expiry, or someone just deleting MFC
entries, when we're in NOCACHE we *know* there's no MFC entry. Add an
install call to make sure pimd's MFC view aligns with the actual kernel
MFC.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
This path here is pretty far on top of the list of issues that operators
will run into and have to debug when setting up PIM. Make the log
messages actually tell what's going on. Also escalate some from
`debug mroute detail` to `debug mroute`.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
PIM_DEBUG_GM_PACKETS
Changing the macros to common so that it can be used for pimv6 debugs as well
to be used for both IGMP and MLD debugs.
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
|
|
Mroute duplicate functions removed and made us hybrid for v4 and v6
Signed-off-by: plsaranya <Saranya_Panjarathina@dell.com>
|
|
The IPv6 `mrt6msg` kernel pseudo-header does not have a length field;
accessing what would be the IPv6 payload length reads zeroes.
Pass down the proper length and use that instead.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
pim6d: use ICMP6_FILTER instead of BPF on mroute
|
|
Since pim_zlookup.c is available for pimv6,
Call pim_zlookup_sg_statistics api for v6.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
|
|
The ICMP6_FILTER option is always checked by the kernel, so the cost is
taken whether or not anything is set there. Use it instead of taking on
additional cost with a BPF program.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
Modified marco name so that it can be reused in mld.
Signed-off-by: Abhishek N R <abnr@vmware.com>
|
|
When pimd has this setup:
src ----- rtr ------ receiver
|
rp
And the receiver sends a *,G join to rtr. When the
src starts sending a S,G, rtr can wait up to one join/prune
interval before sending a S,G rpt prune. This interval
causes the pimreg device to be in the S,G OIL as that the
RP does not know to prune this leg off.
before:
Timestamp: Thu Mar 31 10:15:18 2022 288767 usec
[MROUTE](10.103.0.5,239.0.0.4) Iif: rtr-lan_src Oifs: rtr-lan State: resolved Table: default
Timestamp: Thu Mar 31 10:15:18 2022 288777 usec
[MROUTE](10.103.0.5,239.0.0.4) Iif: rtr-lan_src Oifs: rtr-lan rtr-lan-1 State: resolved Table: default
Timestamp: Thu Mar 31 10:15:18 2022 288789 usec
[MROUTE](10.103.0.5,239.0.0.4) Iif: rtr-lan_src Oifs: pimreg rtr-lan rtr-lan-1 State: resolved Table: default
Timestamp: Thu Mar 31 10:15:49 2022 324995 usec
[MROUTE](10.103.0.5,239.0.0.4) Iif: rtr-lan_src Oifs: rtr-lan rtr-lan-1 State: resolved Table: default
<31 seconds>
After:
Timestamp: Thu Mar 31 12:56:15 2022 501921 usec
(10.103.0.5,239.0.0.27) Iif: rtr-lan_src Oifs: pimreg rtr-lan State: resolved Table: default
Timestamp: Thu Mar 31 12:56:15 2022 501930 usec
(10.103.0.5,239.0.0.27) Iif: rtr-lan_src Oifs: pimreg rtr-lan rtr-lan-1 State: resolved Table: default
Timestamp: Thu Mar 31 12:56:15 2022 502181 usec
(10.103.0.5,239.0.0.27) Iif: rtr-lan_src Oifs: rtr-lan rtr-lan-1 State: resolved Table: default
<sub second>
What is actually happening:
rtr receives a *,G igmp join, sends a *,G join towards the rp
rtr receives a S,G packet <WRVIFWHOLE>
creates the S,G upstream, sends the register packet to the rp
the rp sees that it still has downstream interest so it forwards the packet on
After (up to 60 seconds ) the rtr, sends the normally scheduled join for
the G and sends the S,GRPT prune as part of it.
What is being done to fix it:
In wrvifwhole handling, when pimd detects that this is the FHR
and is not the RP *and* the incoming interface for the *,G
is different than the incomding interface for the S,G immediately
send a single join packet for the G( which will have the S,G RPT
prune in it ). Only do this on the first time receiving the
WRVIFWHOLE.
Ticket: #2755650
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
Mroute and supporting changes
Signed-off-by: plsaranya <Saranya_Panjarathina@dell.com>
|
|
ip source 0.0.0.0 is OK (RFC 3376: 4.2.13.).
Signed-off-by: ron <lyq140hf2006@163.com>
|
|
[manual merge to edit comment, didn't want to incur another cycle]
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
We can use PIMADDR_ANY instead of INADDR_NONE to initalize rp->rpf_addr
when there is no rp configured for group_all.
Signed-off-by: sarita patra <saritap@vmware.com>
|
|
pim6d: get running with ipv6 types throughout
|
|
The int return value is never used. Modify the code
base to just return a void instead.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
Fix up just enough to make us not operate in complete darkness.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
This is just hitting the pim_mroute code with a hammer until it doesn't
print warnings anymore. This is NOT quite tested or working yet, it
just compiles.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
Need a separate constant that is IPv6 when needed. Also assign the
whole struct rather than just s_addr.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
... and replace with `%pSG` printfrr specifier. This actually used a
static buffer in the formatting function, so subsequent formatting would
overwrite earlier uses.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
|
|
Mostly just 2 sed calls:
- `sed -e 's%struct prefix_sg%pim_sgaddr%g'`
- `sed -e 's%memset(&sg, 0, sizeof(pim_sgaddr));%memset(\&sg, 0, sizeof(sg));%g'`
Plus a bunch of fixing whatever that broke.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
Modifying the members of pim_interface which are to be used
for both IPv4 and IPv6 to common names(for both MLD and IGMP).
Issues: #10023
Co-authored-by: Mobashshera Rasool <mrasool@vmware.com>
Co-authored-by: Sarita Patra <saritap@vmware.com>
Signed-off-by: Sai Gomathi <nsaigomathi@vmware.com>
|
|
Revert "pimd: Modifying members of pim_interface to accommodate IPv6 changes"
|
|
|
|
Modifying name of struct igmp_sock to struct gm_sock, which is to be used
by both IPv4 and IPv6(for both MLD and IGMP).
Co-authored-by: Mobashshera Rasool <mrasool@vmware.com>
Co-authored-by: Sarita Patra <saritap@vmware.com>
Signed-off-by: Sai Gomathi <nsaigomathi@vmware.com>
|
|
Modifying the members of pim_interface which are to be used
for both IPv4 and IPv6 to common names(for both MLD and IGMP).
Issue: #10023
Co-authored-by: Mobashshera Rasool <mrasool@vmware.com>
Signed-off-by: Sai Gomathi <nsaigomathi@vmware.com>
|
|
Signed-off-by: Sai Gomathi <nsaigomathi@vmware.com>
|
|
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>
|
|
debug flag checked twice, just keep one.
Signed-off-by: anlancs <anlan_cs@tom.com>
|
|
1. As per RFC 4601 Sec 4.5.7:
* JoinDesired(S,G) -> False, set SPTbit to false.
2. Change the debug type.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
|
|
IGMP packets received from a source that does not match the subnet
of any configured addresses on the receive interface should be
ignored.
Also, find and use the correct IGMP socket object for the received
IGMP packet.
Signed-off-by: Nathan Bahr <nbahr@atcorp.com>
Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
|
|
pimd: avoiding crash in wrvifwhole path
|
|
Observed crash in the wrvif whole path.
RCA: Wrongvif path trying to access pim attributes of pim disabled RPF interface.
This was resulting in Null access.
(gdb) p/x rpf->source_nexthop
$19 = {last_lookup = {s_addr = 0xa282828}, last_lookup_time = 0x59c0de0828c98,
interface = 0x1013e5011300, mrib_nexthop_addr = {family = 0x2,
prefixlen = 0x20, u = {prefix = 0x28, prefix4 = {s_addr = 0xa282828},
prefix6 = {__in6_u = {__u6_addr8 = {0x28, 0x28, 0x28, 0xa,
0x0 <repeats 12 times>}, __u6_addr16 = {0x2828, 0xa28, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0}, __u6_addr32 = {0xa282828, 0x0, 0x0, 0x0}}},
lp = {id = {s_addr = 0xa282828}, adv_router = {s_addr = 0x0}},
prefix_eth = {octet = {0x28, 0x28, 0x28, 0xa, 0x0, 0x0}}, val = {0x28,
0x28, 0x28, 0xa, 0x0 <repeats 12 times>}, ptr = 0xa282828,
prefix_evpn = {route_type = 0x28, u = {_ead_addr = {esi = {val = {0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}, eth_tag = 0x0},
_macip_addr = {eth_tag = 0x0, ip_prefix_length = 0x0, mac = {
octet = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}, ip = {ipa_type = 0x0,
ip = {addr = 0x0, _v4_addr = {s_addr = 0x0}, _v6_addr = {
__in6_u = {__u6_addr8 = {0x0 <repeats 16 times>},
__u6_addr16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0},
__u6_addr32 = {0x0, 0x0, 0x0, 0x0}}}}}}, _imet_addr = {
eth_tag = 0x0, ip_prefix_length = 0x0, ip = {ipa_type = 0x0, ip = {
addr = 0x0, _v4_addr = {s_addr = 0x0}, _v6_addr = {__in6_u = {
__u6_addr8 = {0x0 <repeats 16 times>}, __u6_addr16 = {0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, __u6_addr32 = {0x0,
0x0, 0x0, 0x0}}}}}}, _es_addr = {esi = {val = {0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}},
---Type <return> to continue, or q <return> to quit---q
ip_prefix_length = 0x0Quit
(gdb) p/x rpf->source_nexthop.interface
$20 = 0x1013e5011300
(gdb) p/x rpf->source_nexthop.interface->info
$21 = 0x0 <======================== Pim & Igmp is disabled on this interface
Fix: Return when the rpf interface is not pim enabled
Signed-off-by: Saravanan K <saravanank@vmware.com>
|
|
pimd: (S,G) Route doesn't inherit olist from parent while creation in nocache path
|
|
There exists a path where tmp_oil is used uninited, prevent
this from happening.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
|
pimd: Don't refresh mroute_creation for kernel-installed mroute
|
|
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>
|
|
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>
|
|
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>
|
|
FINISH IT
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
|
Just keep the code cool.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.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>
|
|
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>
|
|
PIM state machine fixes
|
|
const const const your boat, merrily down the stream...
Signed-off-by: David Lamparter <equinox@diac24.net>
|
|
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>
|
|
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>
|
