Subject: Re: [44net] Is there raceroutre machine on 44 net available forpublic ? From: Brian Kantor Brian@UCSD.Edu Date: 03/09/2016 02:37 PM

To: AMPRNet working group 44net@hamradio.ucsd.edu

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