Re: [44net] RIP packet loss - 44net

9 Mar 2016

...
  Subject:
 Re: [44net] Is there raceroutre machine on 44 net available forpublic ?
 From:
 Brian Kantor &lt;Brian(a)UCSD.Edu&gt;
 Date:
 03/09/2016 02:37 PM

 To:
 AMPRNet working group &lt;44net(a)hamradio.ucsd.edu&gt;

 I've never found the cause of this; the rip sender would report protocol
 buffer overflows and never has. The UCSD network can easily take the
 amount of traffic that the rip transmissions constitute, and is not rate
 limited, so I am led to the conclusion that the loss must be along the
 transit path somewhere. Of course, being UDP inside IP, we don't get
 notified of in-transit packet drops so it remains a mystery why this
 is/was happening. 
Well, when you send a few thousand UDP packets from a fast system on a gigabit
ethernet it does not really surprise me that there can be drops somewhere.  Probably
not within the fast infrastructure of a university network, but maybe further along the
path.  There could be queues on interfaces that are slower or loaded with other traffic
and that drop some of the packets.

At that time there was an obscure second transmission of the same RIP data and when
that was dropped, the situation appeared to improve.

The gateway where I was observing the problem is on a 100 Mbit line shared with several
other systems, maybe the drops were occurring locally due to some rate limiting in place
to achieve fair sharing of the bandwidth.  I don't think I observed it on our gigabit
connected gateway, that was installed later.

You could put a small delay between sending the packets or after each small group
of packets.  Also when you are sending the series of packets to all the gateways,
consider to make the inner loop by gateway and the outer loop by packet of the series,
not sending all packets for 1 gateway first and then the series to the next gateway.
The small delay could then be in the outer loop, and each gateway receives its
packets somewhat spaced.

Rob