Unless extremely accurate timekeeping is mission-critical for you there should be no discernible effect for your users, aside from their clocks changing by 2 minutes.
The possible exception is if they declare your NTP server to be “insane” as a result of the large change (which would require you to restart the NTP service on the affected systems to force them to sync the clock – though you can do this without an outage).
While you’re fixing this here are a few other pointers:
-
You should configure your systems that look at external NTP sources to look at several (4-5) servers from the public NTP pool project — preferably geographically appropriate ones.
Having more NTP servers allows the selection algorithm to ignore ones that break/go insane and keep your clock accurate. -
In a configuration like yours I would point
Core Router 1andCore Router 2at external clock sources (not each other).
This gives you two independently-synchronized clocks which should be within a few ms of each other, but if one of your routers goes insane it can’t hurt the other one. -
In a configuration like yours I would point the domain controllers at BOTH core routers (again to protect against one going down).
If you want to protect against a clock going insane you should add a third authoritative NTP server (or list one of your routers twice and hope it’s not the one that loses its mind…)