[ntp:questions] NTP Limited Broadcast

mills at udel.edu mills at udel.edu
Tue Mar 13 16:47:57 UTC 2007


Danny,

You scratch an old wound. When I wrote the first RFC on internet 
subnetting the conventional interpretation of 255.255.255.255 was 
broadcast to the world without limit. I though this a dumb idea and 
intended that broadcasts never went beyond the first-hop gateway.

In review, my document did not say that explicitly; however, Bob Braden, 
who wrote the sequel, did strongly discourage propagation of broadcasts 
beyond the first-hop gateway. Therefore, the considered engineering 
judgement would be that anything other than the subnet bits at the left 
end of the address and other than the one bits at the right end be 
discarded forthwith. If the vendor in question does not understand that, 
switch to a different vendor.

Once upon a time a favorite bogon was a packet with all ones in the 
destination AND source addresses, preferably in an ICMP echo request 
packet. Then measure the Ethernet temperature as result. I named such as 
Chernobyl packets and the result as broadcast storms. Gateways had what 
came to be known as Martian filters that grounded packets with bogus 
source and/or destination addresses. I assume modern gateways have 
equivalent defenses.

Dave

Danny Mayer wrote:
> Kevin D. Casey wrote:
> 
>>I am running NTP 4.2.2 on FreeBSD 6.2 broadcasting to clients on the
>>broadcast address of an internal subnet 192.168.144.0/24 which is
>>192.168.144.255. The server is using 192.168.144.120 on its network
>>interface. The attached switch hardware on the subnet is able to
>>receive the broadcasts and update its clock as an SNTP client. I have
>>also verified the presence of UDP 123 broadcasts using Ethereal. I
>>have a proprietary time recording device also attached to the same
>>broadcast domain that appears to be unable to receive it's updates in
>>this way. Although it is designed to listen for UDP 123 broadcast
>>traffic, the manufacturer is claiming that it will only listen for
>>broadcasts sent to 255.255.255.255. However when I try to reconfigure
>>NTPD to use 255.255.255.255 instead of 192.168.144.255 the broadcast
>>stops working. Can anyone tell me how to configure NTPD to broadcast
>>on 255.255.255.255? -- Kevin D. Casey kevin at kdcasey.net 
> 
> 
> See Bug #779 https://ntp.isc.org/bugs/show_bug.cgi?id=779
> 
> This has become a difficult issue to resolve. Although a socket gets set
> up to accept broadcast packets packets sent to 255.255.255.255 only get
> delivered to the wildcard socket where all packets get dropped. I'm not
> sure why this is but it looks like all O/S's seem to ignore the
> configured socket for this case in favor of the wildcard socket. I'm
> trying to research this issue.
> 
> Danny
> _______________________________________________
> questions mailing list
> questions at lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions
> 




More information about the questions mailing list