Now, all seem normal. Strange case. Maybe you are right in this release, local traffic does not pass AAR or data policy. Or locally generated control (CPU) traffic does not pass. I actually tested in v20.11/17.11 with ping/telnet&ssh traffic in LAB. Will check control syslog traffic too.
Can you do temporary filter in datapolicy by matching local service VPN IP and remote (syslog/cflowd collector server with respective ports) with action drop (don't do drop for all traffic of VPN IP, you may have some routing in LAN and it will also be blocked). Plus, add icmp to this block list. It can be case that, icmp (ping) blocked, because it is user generated traffic (like regular transit, dataplane traffic), but syslog is still not blocked because it is control traffic. Then, it is definitely control plane issue. Router generated dataplane passes AAR/Datapolicy, control traffic is not.
Below is from my lab, as you see I have 10.2.1.254 on service side as router IP and it matches AAR policy. It matches seq 1 (as you see in upstream feature and policy) and actual local color is biz-internet, while preferred local is public-internet (I've higher loss in my lab for public-internet transport while I do this test). You can also use NWPI tool (needs, data stream to be enabled).
interface GigabitEthernet2
vrf forwarding 1
ip address 10.2.1.254 255.255.255.0
no ip redirects
load-interval 30
negotiation auto
arp timeout 1200
no mop enabled
no mop sysid
end
However, I configured syslog on router towards one of the remote sites. Also, did telnet (dataplane traffic) from local router as telnet client to remote core switch, both are shown in NWPI tool and for both tool shows AAR/Datapolicy checks with respective SLA class, matching case etc. The one test is left, doing the same check (you can begin to do test in datapolicy with drop for syslog traffic for example) in your environment (20.7 version). In my lab (v20.11) everything works as I mentioned. Both locally generated dataplane and control plane pass both AAR and Datapolicy
