Một trong những máy chủ NTP bên ngoài (máy chủ chính - hiện tại) chúng tôi đang sử dụng làm nguồn dường như không đáp ứng với các cuộc gọi NTP. Thật không may, trên bộ định tuyến lõi của chúng tôi (Cisco 6509), chức năng NTP đã không chuyển sang máy chủ bên ngoài NTP thứ cấp như mong đợi. Do đó, bộ định tuyến lõi của chúng tôi, nguồn NTP nội bộ chính của chúng tôi bị trễ 2 phút.

Tôi dự định khắc phục sự cố bộ định tuyến bên ngoài bằng cách làm cho nguồn NTP bên ngoài là nguồn hiện đang hoạt động. Tôi đang tự hỏi, việc thay đổi 2 phút sẽ ảnh hưởng đến người dùng và dịch vụ của tôi đến mức nào? Đặc biệt kể từ những ngày này, chúng tôi chủ yếu dựa vào xác thực dựa trên chứng chỉ.

Chúng tôi là một cửa hàng Windows / Cisco.

Thiết lập NTP nội bộ:

[Bộ định tuyến lõi 1 / Cisco 6509]:
tìm kiếm hai máy chủ NTP bên ngoài (trong đó máy chủ chính không phản hồi các cuộc gọi NTP)

[Bộ định tuyến lõi 2]:
Đồng bộ hóa với Bộ định tuyến lõi 1 (chính), bộ định tuyến bên ngoài hoạt động (phụ)

[Các thiết bị mạng khác của Cisco]:
Đồng bộ hóa với bộ định tuyến Core 1 (chính), bộ định tuyến lõi 2 (phụ)

[Bộ điều khiển miền]:
Đồng bộ hóa với bộ định tuyến lõi 1

[Tất cả máy khách / máy chủ windows]:
Đồng bộ hóa với bộ điều khiển miền

Trừ khi thời gian cực kỳ chính xác là nhiệm vụ quan trọng đối với bạn, không nên có hiệu lực rõ rệt cho người dùng của bạn, ngoài đồng hồ của họ thay đổi 2 phút.

Ngoại lệ có thể xảy ra là nếu họ tuyên bố máy chủ NTP của bạn là "điên" do thay đổi lớn (sẽ yêu cầu bạn khởi động lại dịch vụ NTP trên các hệ thống bị ảnh hưởng để buộc họ đồng bộ hóa đồng hồ - mặc dù bạn có thể làm điều này mà không cần cúp điện).

Trong khi bạn đang sửa lỗi này, đây là một vài gợi ý khác:

• Bạn nên định cấu hình hệ thống của mình xem xét các nguồn NTP bên ngoài để xem xét một số (4-5) máy chủ từ dự án nhóm NTP công cộng - tốt nhất là phù hợp về mặt địa lý.
  Có nhiều máy chủ NTP cho phép thuật toán lựa chọn bỏ qua những cái bị hỏng / mất trí và giữ cho đồng hồ của bạn chính xác.

• Trong một cấu hình như của bạn, tôi sẽ chỉ Core Router 1và Core Router 2tại các nguồn đồng hồ bên ngoài (không phải nhau).
  Điều này cung cấp cho bạn hai đồng hồ được đồng bộ hóa độc lập, trong vòng một vài ms với nhau, nhưng nếu một trong các bộ định tuyến của bạn phát điên, nó không thể làm tổn thương cái kia.

• Trong một cấu hình như của bạn, tôi sẽ trỏ các bộ điều khiển miền vào các bộ định tuyến lõi BOTH (một lần nữa để bảo vệ chống lại sự cố đi xuống).
  Nếu bạn muốn bảo vệ đồng hồ phát điên, bạn nên thêm một máy chủ NTP có thẩm quyền thứ ba (hoặc liệt kê một trong các bộ định tuyến của bạn hai lần và hy vọng nó không phải là một trong những mất mát tâm trí của nó)

Mặc định tên miền cho Windows cho phép thời gian tắt +/- 300 giây trước khi xác thực ngừng hoạt động, vì vậy bạn sẽ ổn. Đây là một bài viết khá đầy đủ về chủ đề này , thậm chí còn đề cập đến cách thay đổi khả năng chịu đựng thời gian của bạn với GPO cấp tên miền. Đó là tại Computer Configuration-> Policies-> Windows Settings-> Security Settings-> Account Policies-> Kerberos Policy-> Maximum tolerance for computer clock synchronization.

Điều đó nói rằng, bạn nên có nguồn thời gian có thẩm quyền (thường là Bộ điều khiển miền giữ vai trò giả lập PDC trong miền Windows) với một ntpnguồn bên ngoài , như thế nào pool.ntp.org. Thông tin thêm từ Technet, ở đây .

Và để đáp lại câu trả lời khác, điều này không yêu cầu thời gian chết. Chỉ cần trỏ lại nguồn thời gian có thẩm quyền của bạn và phần còn lại của các máy tính gia nhập miền cũng sẽ tự đồng bộ hóa.

EDIT: vì @ voretaq7 đã đề cập đến nó, tôi nên chỉ ra rằng chúng ta chỉ có một hệ thống nhìn thấy một nguồn thời gian bên ngoài, trình giả lập PDC của chúng ta. Tất cả các thiết bị, bao gồm cả đồng bộ hóa thiết bị mạng với nó. Chúng tôi thấy đây là một sự sắp xếp tốt hơn, vì thiết bị mạng sẽ không từ chối xác thực do sai lệch thời gian, nhưng các máy tính gia nhập miền sử dụng Kerberos (là tất cả trong số chúng, đối với chúng tôi) sẽ. Vì vậy, về mặt này, việc có thời gian chính xác trên thiết bị mạng của chúng tôi không quan trọng lắm, nhưng chắc chắn là trên các hệ thống Windows của chúng tôi, vì chúng tôi cũng chạy phần mềm giữ thời gian cho nhân viên hàng giờ trên máy chủ Windows.

Các máy khách Windows thực sự sẽ không gặp vấn đề gì khi đăng nhập. Mô tả của Maximum tolerance for computer clock synchronizationchính sách là khá không chính xác những ngày này.

Một khách hàng có đồng hồ sai nghiêm trọng sẽ nhận được phản hồi từ máy chủ thiết lập độ lệch giữa các đồng hồ của họ - sau đó xác thực sẽ diễn ra bình thường (với ứng dụng khách tự điều chỉnh để giải thích cho độ lệch của đồng hồ rõ ràng).

Mô tả là đúng về một điều; chính sách vẫn thiết lập hiệu quả bộ hẹn giờ cho các cuộc tấn công phát lại - nhưng, về mặt lưu lượng truy cập hợp pháp, thông tin liên lạc mạnh mẽ chống lại các sai lệch đồng hồ lớn.

Xem bài viết MS KB này để biết thêm thông tin.

Bạn có thể muốn xem xét việc xem (các) máy chủ NTP khác ngoài thiết bị cisco cốt lõi của mình: lưu lượng truy cập NTP nghiêm trọng mang lại tải cpu cao cho thiết bị cisco có thể dẫn đến sự cố mạng.

Rõ ràng là bạn không thể sắp xếp một thời gian chết nhỏ, phải không? Tôi sẽ cố gắng ngừng hoạt động để khởi động lại dịch vụ ntp trên tất cả các máy chủ bị ảnh hưởng. Nếu điều đó là không thể, thì bạn phải chờ một thời gian.

(Tôi sẽ bình luận về câu trả lời của vortaq7, nhưng tôi nghĩ nó đáng được nhắc lại theo cách riêng của mình, vì nhiều người mắc lỗi này.)

Bạn cần ít nhất 3 nguồn (tốt nhất là 4-6) cho thuật toán của NTP để hội tụ chính xác thời gian chính xác. Nếu NTP chỉ có hai nguồn chính và cả hai đều ở ngoài một lượng đáng kể, NTP không có cách nào để biết nên tin tưởng vào nguồn nào.

Sự giúp đỡ lớn nhất đối với tôi để hiểu điều này là sơ đồ trên trang 9 của bản thiết kế Mặt trời "Sử dụng NTP để điều khiển và đồng bộ hóa Đồng hồ hệ thống, phần III: Giám sát và khắc phục sự cố NTP". Tài liệu này biến mất khỏi tầm nhìn khi Oracle mua Sun, nhưng bạn vẫn có thể tìm thấy nó trên Wayback Machine . Cũng có rất nhiều lượt truy cập trên web nếu bạn tìm kiếm tiêu đề.