Aerial sfn slot mismatch issue

Hi, we are trying to configure the Aerial testbed with GH200 and Benetel RU. But when starting we get the below sfn slot mismatch issue. Sync seems to be fine and logs are also given below. We have also setup tuned-adm to ‘real-time’ as per in another discussion with same error. RU MAC and vlan were also confirmed and set on cuphycontroller file. Can you please help on how to troubleshoot this?

PTP sync output:

cpu allowed list for ptp seems to have setup with 0-71. so does that need to change? I have attached current ptp config files also.

================ RUNTIME CPU AFFINITY ================

PID=1866605 CMD=/usr/local/sbin/ptp4l -f /etc/ptp.conf
PID TID PSR CLS RTPRIO PRI STAT COMMAND
1866605 1866605 66 TS - 19 Ss ptp4l
Cpus_allowed_list: 0-71
Mems_allowed_list: 0-1
pid 1866605’s current affinity list: 0-71

PID=1866737 CMD=/usr/local/sbin/phc2sys -s aerial00 -c CLOCK_REALTIME -n 42 -O 0 -R 256 -u 256 -w
PID TID PSR CLS RTPRIO PRI STAT COMMAND
1866737 1866737 69 TS - 19 S phc2sys
Cpus_allowed_list: 0-71
Mems_allowed_list: 0-1
pid 1866737’s current affinity list: 0-71

ptp config:
[global]

dataset_comparison G.8275.x

G.8275.defaultDS.localPriority 128

maxStepsRemoved 255

logAnnounceInterval -3

logSyncInterval -4

logMinDelayReqInterval -4

G.8275.portDS.localPriority 128

network_transport L2

domainNumber 42

ptp_minor_version 0

time_stamping hardware

tx_timestamp_timeout 30

clientOnly 1

clock_servo pi

step_threshold 1.0

egressLatency 28

pi_proportional_const 4.65

pi_integral_const 0.1

[aerial00]

announceReceiptTimeout 3

delay_mechanism E2E

network_transport L2

cuphycontroller config:

cells:

- name: O-RU 0

  cell_id: 1

  ru_type: 1

  \# set to 00:00:00:00:00:00 to use the MAC address of the NIC port to use

  src_mac_addr: e8:9e:49:92:5a:50

  dst_mac_addr: 8c:1f:64:d1:16:0a

  nic: '0000:01:00.0'

  vlan: 3

  pcp: 0

Has the Benetel DU MAC address been configured?

RU-side MAC and VLAN has been configured as below. In the cuphycontroller also MAC has been configured.

c_plane_du_mac=e8:9e:49:92:5a:50
u_plane_du_mac=e8:9e:49:92:5a:50
u_plane_du_vlan_uplink=3
u_plane_du_vlan_downlink=3
c_plane_du_vlan=3

It looks correct. Could you please confirm which switch model is being used? The switch also needs to be configured with VLAN 3.

You can assign static IP addresses to the GH200 aerial00 interface and the O-RU Ethernet interface, then use the ping command to verify network connectivity.

Based on the error screenshot you provided, the issue appears to be caused by a network connectivity failure rather than an incorrect configuration.

I also checked the VLAN 3 path as suggested and it was completed successfully. Is there any other method to confirm the connectivity? gnb and cubb are showing sfn slot mismatch and is this related to RU connectivity?

saddarag24@aerial1:~$ ping -I vl3 -c 4 192.168.3.2
PING 192.168.3.2 (192.168.3.2) from 192.168.3.1 vl3: 56(84) bytes of data.
64 bytes from 192.168.3.2: icmp_seq=1 ttl=64 time=0.191 ms
64 bytes from 192.168.3.2: icmp_seq=2 ttl=64 time=0.181 ms
64 bytes from 192.168.3.2: icmp_seq=3 ttl=64 time=0.200 ms
64 bytes from 192.168.3.2: icmp_seq=4 ttl=64 time=0.182 ms

--- 192.168.3.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3053ms
rtt min/avg/max/mdev = 0.181/0.188/0.200/0.007 ms

tcpdump on the VLAN interface also shows bidirectional ICMP traffic between the DU and RU MAC addresses:

e8:9e:49:92:5a:50 > 8c:1f:64:d1:16:0a
192.168.3.1 > 192.168.3.2: ICMP echo request

8c:1f:64:d1:16:0a > e8:9e:49:92:5a:50
192.168.3.2 > 192.168.3.1: ICMP echo reply

Hi @saddarag24 ,

The error messages indicate Aerial L1 didn’t receive any UL U-plane packets.

There are two possible causes coming to my mind now:

  1. Misconfiguration of FH parameters
  2. O-RU’s in-sync

For 1, have you captured the FH packets to verify that the dst/src MAC addresses, VLAN ID, PCP, eAxC IDs are correctly configured? If they do not match the parameters in the cuphycontroller yaml, the NIC doesn’t pass received packets to GPU memory.

Also, did you check if Benetel’s O-RAN delay profile matches the default parameters? If the O-RU received C-plane messages early or late, it will drop the messages and will not send the corresponding U-plane packets.

Thank you.