In both 17.9.4 and 17.12.2 NDP appears to be broken between only C9136I-B and only on 2.4 and 5ghz - 6ghz works fine. This happens whether I set ndp-mode auto, ndp-mode off-channel, or ndp-mode on-channel in the 2.4 and 5ghz RF profiles. The default setting for the RF profiles is ndp-mode auto, which results in all radios on C9136I-B getting set to on-channel NDP. The same is true for CW9166I-B which does not experience this problem. NDP type is currently set to transparent (default) for 2.4GHz, 5GHz, and 6GHz.
The effect of this for me is that TPC is totally broken on 2.4 and 5GHz on only between neighboring C9136I-B APs. DCA appears to be assigning channels, but maybe not optimally. C9136I-B are discovering 9130AXI-B in a neighboring building as neighbors, but 9136s themselves cannot "hear" each other as neighbors on 2.4 and 5ghz and TPC is completely broken on those bands, resulting in max power levels on every radio. Workaround I'm using for that at the moment is to hard cap 2.4Ghz tx level in the RF profile.
The documentation in the 9800 guide for NDP is out of date, so you have to refer to https://video.cisco.com/detail/video/6249386397001 at around the 14 minute mark for how on-channel NDP is supposed to work. Appears that the 6E APs do support on-channel NDP, but the 9800 config guide is out of date: https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/17-12/config-guide/b_wl_17_12_cg/m_configuring_ndp-mode_on_access_point.html
Debug neighbor rx/tx/detail from an affected 9136 shows an apparent issue:
Nov 27 12:37:57 ap-p-commons6f28 kernel: [*11/27/2023 12:37:57.9767] chatter: cwx3/rrm_receive :: RRMReceive NDP RX: TA:[24:16:1B:18:DD:18] TLV:1 band 2 channel 37
Nov 27 12:37:57 ap-p-commons6f28 kernel: [*11/27/2023 12:37:57.9767] chatter: cwx3/rrm_receive :: RRMReceive::process_neighbor_pkt_check interface 3 band 2 rrm_band_id 3 rrm_context 0xffffff8bce75ad28 radio 0xffffff8bce540000
Nov 27 12:37:57 ap-p-commons6f28 kernel: [*11/27/2023 12:37:57.9767] chatter: cwx3/rrm_receive :: RRMReceive process_neighbor_pkt_check NDP Rx: [24:16:1B:18:DD:18] TLV length 104
Nov 27 12:37:57 ap-p-commons6f28 kernel: [*11/27/2023 12:37:57.9768] chatter: cwx3/rrm_receive :: RRMReceive Dropping an invalid NDP rx neighbor 24:16:1B:18:DD:18(3) packet
24:16:1B:18:DD:18 is a neighboring 9136.
I do have a TAC case open on this but curious if anyone else with 9136 deployment has noticed this. It does not necessarily cause a problem in all environments to have all the radios at max power but I would consider it a severe issue because it completely breaks TPC which is a foundational feature here.
