Hi,
It's a quite interesting problem. I am not familiar with Cisco but I will still share my opinion.
From your snoop I noticed that the Junos device is declaring the adjacency down at packets 56, 112, 164, 238, etc...
Since the configured dead interval is 4s we must assume that the last received and processed Hello from the Cisco device was sent 4s + espilon earlier. If we check again the snoop we notice that 4 seconds earlier the Cisco device always sends an unicast Hello message to the Junos device. And apparently Junos always ignores the following multicast Hellos.
From RFC2238:
On broadcast networks and physical point-to-point networks,
Hello packets are sent every HelloInterval seconds to the IP
multicast address AllSPFRouters. On virtual links, Hello
packets are sent as unicasts (addressed directly to the other
end of the virtual link) every HelloInterval seconds. On Point-
to-MultiPoint networks, separate Hello packets are sent to each
attached neighbor every HelloInterval seconds.
I am assuming your LAG is a regular broadcast network. Thus I don't see the point for the Cisco device to send unicast Hello packets. How is Junos supposed to deal with that? On its side Junos never sends unicast Hellos.
My idea: maybe Junos after seeing the first erroneous unicast Hellos is incorrectly discarding the following valid multicast Hellos.
As a mean to test this hypotesis, we could check the configuration on the Cisco device or we could try to configure a firewall filter on the Junos device to discard unicast Hellos. Not easy at first sight. How to distinguish unicast Hellos from other valid unicast OSPF messages? From the snoop it seems that all unicast Hellos sent from the Cisco have a packet size of 94... Well... this sounds crazy but why not try? 🙂