Looks like with my new(ish) network setup I signed myself up for some pain in figuring out intermittent packet loss 😬
It involves hardware-accelerated NAT, a DSA-abstracted switch, VLAN-aware bridges, and a loop through ISP's first hop. Oooof
Well, judging by the mirror of the WAN port, the issue's on the ISP side. The hope for solving a once in an hour or so problem is zero with them.

My ISP lets me get up to 5 public IP addresses through DHCP. The "primary" such client works fine, but the secondary experiences intermittent connectivity loss, sometimes for 40+ seconds.

I need to sleep on this and look at traffic captures again. Wonder if it has anything to do with lack of outgoing traffic.

But then the DHCP lease should be valid for the entire hour, why would it fail this early 🤔

Continuing the "periodic packet loss" saga. Set up a more predictable sniffer with two USB NICs and a regular Linux software bridge with all offloading disabled.

Reproduced the problem, packets occasionally stop arriving from the BNG.

Seems to be triggered by a lack of "useful" traffic from the affected client. As soon as an NTP request comes from an affected client, ICMP immediately resumes. ICMP thus doesn't count as "activity".

Same exact thing on a capture from a few days ago too.

My main router has such traffic all the time, that's likely why I don't see that problem there.

But on a host that's mostly idling now it's much more noticeable.

The timings don't look particularly even/pretty either

* 6 seconds since last ARP exchange
* 2 min 7 sec since last TCP outgoing packet
* 7 min 50 sec since last DHCP exchange

NTP queries happen every 5 minutes.
DHCP lease is 1 hour.

… but then I also had SSH connections die on multiple occasions, which already have aggressive TCP-level and SSH-level keepalives every 5 seconds.