# The issue of NTP requests exceeding bandwidth load

**URL:** <https://community.ntppool.org/t/the-issue-of-ntp-requests-exceeding-bandwidth-load/3588>\
**Category:** Server operators\
**Created:** [November 3, 2024, 10:32am UTC](https://community.ntppool.org/t/the-issue-of-ntp-requests-exceeding-bandwidth-load/3588 "2024-11-03T10:32:18Z")\
**Posts on this page:** 1\
**Showing post:** 54

<div class="post-metadata">

**Author:** ![davehart](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/davehart/32/1411_2.png) [@davehart](https://community.ntppool.org/u/davehart)\
**Post date:** [November 24, 2024, 4:49am UTC](https://community.ntppool.org/t/the-issue-of-ntp-requests-exceeding-bandwidth-load/3588/54 "2024-11-24T04:49:38Z")

</div>

> [@davehart](#):
>
> First off, does `nslookup time.cloudflare.com.` return any IP addresses for you?
> 
> If you do get IP addresses, try using sntp or ntpdate from the NTP distribution to try using [time.cloudflare.com](http://time.cloudflare.com):
> 
> `ntpdate -d time.cloudflare.com`
> 
> or add them to your NTP server’s configuration with:
> 
> `server time.cloudflare.com iburst`
> 
> and then take a look at its status and see if it’s serving you time.

No replies. It doesn’t need to be @kkursor, but would someone in Russia please check if Cloudflare servers are working from within Russia? They are included in \*.ru.pool.ntp.org but keep in mind with their IP addresses being anycast from many different data centers, just because monitors outside Russia say it’s working and it is in the zone doesn’t mean it’s working for clients inside Russia. My hunch is it does indeed work inside Russia and that’s letting clients using \*.ru.pool.ntp.org continue to work despite what I suspect is a malicious flood of NTP queries to that zone, but it would be groovy to know one way or the other.

If you have access to ntpdate, try:

```auto
nslookup time.cloudflare.com.

```

Does the response include the IP addresses below? Then please try:

```auto
ntpdate -d 162.159.200.1
ntpdate -d 162.159.200.123

```

and if you have IPv6, also:

```auto
ntpdate -d 2606:4700:f1::1
ntpdate -d 2606:4700:f1::123

```

The output should make it clear if you’re getting responses and how close they suggest your system clock is.

If you don’t have access to ntpdate, you can test by adding those addresses to your NTP server configuration and looking at the status after a few minutes to see if you’re getting useful responses.

---

_[View the full topic](https://community.ntppool.org/t/the-issue-of-ntp-requests-exceeding-bandwidth-load/3588)._
