The customer experiences unexpected ddos-protection protocol resolve violation. 
All interfaces were configured with /30 subnet, so theoretically resolve violation should not occur on the device. 

The root cause was investigated and fixed by PR1741461. 
Please refer to the PR for fixed-release information. 

The ddos-protection protocol resolve violation is triggered when sflow monitoring is enabled on ECMP routes. The issue only occurs when both conditions are met. 

user@host> show ddos-protection protocols violations    
Packet types: 71, Currently violated: 1

Protocol    Packet      Bandwidth  Arrival   Peak      Policer bandwidth
group       type        (pps)      rate(pps) rate(pps) violation detected at
resolve     aggregate   500        3275      12308     2023-06-19 16:31:35 IST
          Detected on: FPC-0

This will not cause a service impact, but sflow will be impacted as sampled packets will be dropped and sflow packets will not be sent to the collector. 

On Junos based QFX platforms having sflow enabled with ECMP, the packet received by the host will not have all the data it needs to populate the metadata.
This packet received will be inserted back into the chip to get the required data and this injected packet uses the feature TAL(Trap after lookup) which generates an interrupt and send this back to the host.
When this packet is received back at the host, it has the resolve ddos bit set which is resulting in violation.

Due to this issue, sflow will not send samples to the collector.
It can be verified by output of CLI command "show sflow collector" which will not increment counter of packets going towards collector.

Below CLI command can be used to check inbound resolve packets detected by ddos-protection:

user@host>show ddos-protection protocols resolve violations

Please refer to the PR for fixed-release information.