ASA's legacy syslog timestamp, the default logging timestamp format, has no timezone in it, so if the ASA clock isn't on UTC and your collector assumes it is, its logs land hours away from the router's. Built in my home lab with IOS XE 17.18.2 (IOL), ASAv 9.24(1) and an Alpine collector, one ICMP packet was permitted by the router and then denied by the ASA. With the ASA on UTC-8, a UTC timeline put the deny almost eight hours before the permit. Putting the ASA back on UTC and turning on logging timestamp rfc5424 (which stamps 2026-10-21T21:37:51Z) restored the real order.
Both Cisco devices sent syslog over separate data links to the collector and used its lab NTP service. A single ICMP echo traveled from the collector through IOL to ASAv. IOL logged the permit; ASA logged the deny. A different destination identified each phase, so ACL aggregation did not mix them.
The transit link had a fixed 1.5-second delay throughout. That makes the order visible with ASA's whole-second timestamp precision. It is a test setting, not a latency result.
If you need the base configuration first, see syslog on Cisco IOS XE and ASA syslog logging.
Baseline: IOS XE and ASA both on UTC
Both devices used UTC. The IOS XE permit preceded the ASA deny. The leading * on the router line means its clock was not yet NTP-synchronized; the Limits section below covers that. In the ASA line, dst management: is just the name of the ASA interface the route to that destination points at, not a management path.
<190>49: *Oct 21 2026 21:31:49.550 UTC: %SEC-6-IPACCESSLOGDP: list EVENT52 permitted icmp 10.52.10.2 -> 198.18.52.11 (8/0), 1 packet
<164>Oct 21 2026 21:31:50 ASA52 : %ASA-4-106023: Deny icmp src transit:10.52.10.2 dst management:198.18.52.11 (type 8, code 0) by access-group "EVENT52" [0x39339678, 0x0]
Fault: ASA on UTC-8 with a timezone-less timestamp
I changed only the ASA timezone, with clock timezone BAD -8. BAD is just the label I gave a -8 hour zone; any name does the same. NTP and the forwarding policy stayed in place, and the ASA still reported its clock synchronized. The legacy ASA timestamp text did not include a timezone, so a timeline that assumed both timestamps were UTC read 13:32:04 as UTC and put the deny almost eight hours before the permit. This was a collector parsing/timezone error, not packet reordering: the packet path and the delay never changed.
<190>50: *Oct 21 2026 21:32:02.743 UTC: %SEC-6-IPACCESSLOGDP: list EVENT52 permitted icmp 10.52.10.2 -> 198.18.52.12 (8/0), 1 packet
<164>Oct 21 2026 13:32:04 ASA52 : %ASA-4-106023: Deny icmp src transit:10.52.10.2 dst management:198.18.52.12 (type 8, code 0) by access-group "EVENT52" [0x39339678, 0x0]
Why the legacy ASA timestamp misorders events
The legacy ASA format, Oct 21 2026 13:32:04, is local time in whole seconds with no zone. The BSD syslog timestamp in RFC 3164 has no year or zone either, so the collector has to assume one. RFC 5424 requires every timestamp to carry a zone, either Z or an offset. IOS XE shows its zone only when service timestamps includes show-timezone, which is why the router lines here end in UTC. A parser that knows the ASA's configured offset can recover the fault timeline by applying -08:00; nothing in the message itself tells it to.
Fix: UTC clock plus logging timestamp rfc5424
I restored clock timezone UTC 0 on the ASA and enabled logging timestamp rfc5424. IOS XE kept service timestamps log datetime msec localtime show-timezone year with its clock on UTC, and both devices reported NTP synchronized before this event. The same event path now produced timestamps that sorted in the observed order. I changed both at once, so this run doesn't isolate rfc5424 by itself; Cisco documents that rfc5424 timestamps are always UTC.
<190>53: Oct 21 2026 21:37:50.208 UTC: %SEC-6-IPACCESSLOGDP: list EVENT52 permitted icmp 10.52.10.2 -> 198.18.52.13 (8/0), 1 packet
<164>2026-10-21T21:37:51Z ASA52 : %ASA-4-106023: Deny icmp src transit:10.52.10.2 dst management:198.18.52.13 (type 8, code 0) by access-group "EVENT52" [0x39339678, 0x0]
The rfc5424 option changes only the timestamp. The fixed ASA line goes straight from the <164> priority to the timestamp, without the 1 VERSION field that RFC 5424 requires after the priority, so it isn't a full RFC 5424 message. Test your parser against the payload your ASA actually sends.
The collector kept receipt times separately from the timestamps inside the messages. The packet captures and matching ICMP source/destination tied the two logs to one event. Receipt time alone does not establish when a remote event happened; neither does a timestamp whose timezone is unknown.
Reproduce it: IOS XE and ASA config lines
The relevant config lines from the fixed run:
! IOS XE 17.18.2 (IOL)
service timestamps log datetime msec localtime show-timezone year
ip access-list extended EVENT52
10 permit icmp host 10.52.10.2 198.18.52.0 0.0.0.255 log
interface Ethernet0/1
ip access-group EVENT52 in
logging source-interface Ethernet0/1
logging host 10.52.10.2
ntp server 10.52.10.2 maxpoll 4
! ASAv 9.24(1)
access-list EVENT52 extended deny icmp host 10.52.10.2 198.18.52.0 255.255.255.0
access-group EVENT52 in interface transit
logging enable
logging timestamp rfc5424
logging trap informational
logging device-id hostname
logging host lognet 10.52.20.2
ntp server 10.52.20.2 source lognet prefer
For IOS XE, configure UTC, timestamp year/timezone/milliseconds, an ingress ACL permit with log, a syslog destination and NTP. For ASA, configure the matching ingress deny, logging enable, logging host, logging timestamp, UTC and NTP. Set the collector's route to the event subnet through the router. The echo is supposed to fail: the deny is the observation.
Apply clock timezone BAD -8 on the ASA for the fault. Restore clock timezone UTC 0 and use logging timestamp rfc5424 for the fix. Cisco's ASA 9.24 logging guide describes the UTC timestamp behavior.
Limits: NTP sync, UDP loss and whole-second ASA timestamps
ASAv reported synchronized during baseline and fault. IOS XE had selected the collector but was still measuring drift (loopfilter state is 'FREQ') and reported Clock is unsynchronized, which is why its baseline and fault lines carry a leading *. I waited for its explicit synchronized status before sending the fixed-run echo, so both devices were synchronized only in the fixed run. Check NTP status on the devices themselves; a configured server or a selected peer does not prove synchronization. The NTP source here was chrony's local stratum mode serving the VM's own clock, with no check against external UTC. UDP syslog can also lose messages, and I didn't test loss. ASA timestamps are whole seconds and device clocks still have finite error, so this lab demonstrates an eight-hour timezone mistake and its correction, not sub-second causal ordering.
I tested IOS XE and ASA only; FTD wasn't part of this lab.
For the full NTP, SNMP and logging setup on an ASA, see ASA management access.