A few notes below paul On Jun 29, 2014, at 5:04 AM, Robert Jarratt <robert.jarratt at ntlworld.com> wrote: I think this was discussed not too long ago, but I can t find the email thread. Sorry, this is quite a long email. ... So here are some interesting things about the above information. 1. I am supposed to send out the Ethernet Router Hello every 15 seconds. From my router log, that is exactly what happens (at :18, :33, :48 etc). However the packet sniffer sees extra packets inserted. I have no idea where these packets are coming from (although my suspicion is winpcap, see later). 2. 8.400 seems to send its Ethernet Router Hello every 15 seconds, but repeats them several times at 1-second intervals. In the extract above it is repeated 3 times, then 3 times, then 5 times. The rule is that router hellos are sent every hello time, or whenever the content of the message changes (different DR, different router list, change in router priority, etc.). Hellos sent when a change occurs are limited to one per second. 3. For a node to decide to drop an adjacency (ie to exclude it from the Ethernet Router Hello message), it must fail to see an Ethernet Router Hello for 3xHello Timer (Hello Timer is 15 seconds by default, so 45 seconds). Clearly my side has sent several Ethernet Router Hello messages in that time. If this was UDP dropping packets, then I would have hoped that it would not drop my particular ones 3 times in a row over a period of 45 seconds. So, somehow, my Ethernet Router Hello messages are being dropped on their way to 8.400. However, this can t be outbound from 5.1023, because if that was the case then all my adjacencies would all go down at the same time. At any one time, only adjacency goes down. This suggests that the packet is somehow getting lost towards the end of its journey to 8.400. What kind of node is 8.400? 47.556 is another one that appears to have this problem, I see that one is SIMH. I am wondering if pcap/winpcap might be implicated here. The reason is that I noticed winpcap seems to drop incoming packets if you have sent a burst of outbound packets. In my router I was sending all the DECnet Level 1 Routing messages, all at the same time and getting some problems similar to this with a node local to my network, because my router did not see the packets coming from the other node, even though the sniffer could see them. I changed my router code to send the Level 1 Routing messages with a 1-second delay between them, and that problem went away. So, I am wondering if the remote nodes I have this problem with are SIMH nodes? Yikes. DECnet assumes that data links don t have defects like that. If you need a workaround like that, chances are things won t work anyway, because the nodes you re talking to will not do packet pacing like that. paul