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