ntpd strange behaviour

the nomodify on the restrict doesn't allow it to be kept up to date...
it should be able to modify the clock according to your time source.

I didn't get your this statement

"the nomodify on the restrict doesn't allow it to be kept up to date.."

I am a bit confused as again you said, it should be able to synchronize the time...

restrict {IP of time1} mask 255.255.255.255 nomodify notrap noquery

this tell that the system "IP of time1 is NOT allowed to modify the time, not allowed to trap and not allowed to query...

So you can only use it to query & monitor the time difference with you system with ntpq /p

You most probably meant to do:
restrict {IP of time1} mask 255.255.255.255  notrap noquery

Are you sure of it ?

http://www.brennan.id.au/09-Network_Time_Protocol.html says something different.

Y're right when i checked on my system i did change two things (nomodify together with notrust...) the notrust caused the non syncing.

Does your firewall allow packets from udp 123 <-> 123  (ntpdate,  the program that jumps your clock doesn't need 123 as it's source port)

and the name time1.server & time2.server actually do translate to the addresses {IP of time1}  & {IP of time2}

You could check if traffic runs by using:

tcpdump -vvni {outside interface} udp port 123

and check if there is actual traffic.
Also what stratum are time1.server & time2.server can you supply a ntpq -pn from that system?  {You ay obfusciate addresses if needed, but keep them distinct & consistent please}

I have already checked firewall rules. They allow upd port 123 and I see servers communicating with tcpdump...

In one of the server, I also see

frequency error -509 PPM exceeds tolerance 500 PPM

so it looks like you local clock is unstable to your kernel.
Does you VM get enough CPU time?
I have seen problems running VM's on windows with MS's virtual server (2003).  Most of the time the clock couldn't be kept right
(drift of about seconds per 2-3 minutes, for this system I settled to run ntpdate every minute..., ntpd couldn't get synced)

Maybe you need a lower maxpoll to get it tighter?

Here is an article about stability.... (500 is real bad...)
http://www.ntp.org/ntpfaq/NTP-s-sw-clocks-quality.htm

Another thing that MIGHT (unsure) help (if using VMware's ESX )
is the next link:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427

I have a question....

Is this statement really needed ?? What is the main purpose of this statement when time1 is not configured to sync its time with this server ??

restrict {IP of time1} mask 255.255.255.255 nomodify notrap noquery

It depends on the default that has been setup.
if the default disallows any changes to the system ( notrust or ignore )
then you need to add the options nomodify etc. to allow everything except those options.

so:
   restrict time1
would allow everything.
(including changing settings about trust and how to converge, stratum etc.)
to restrict that nomodify, you don't want to send trap (signals to anybody)
and noquery means you don't want that system to ask the time at your system.

the time server obviously needs to allow query to everybody...

i think i put you in confusion..

ok...what i meant to say is , do i need the following statement in ntpd.conf of client server (the one which is to be synchronized ?)

restrict {IP of time1.server} mask 255.255.255.255 nomodify notrap noquery

*time1.server is the time server with which we are synchronizing.

The firewall doesn't allow any incoming udp traffic to port 123 . In that case, what is the use of the above statement ? Does it make any difference in deleting it ??

well , the local firewall rule restrict traffic to port 123 of this machine. But the rule allows outgoing traffic to port 123 to the time server.

Is that line still required in that case?

ntp only acts on queries with an answer. if there is no query there will be no answer. (the exception is multicase timesync signaling).

So if you allow outgoing queries but block answers you will not receive time info.
If remote cant sent you queries, you will not answer.

So no you wouldn't need the restrict to enlarge the possibilities. But if you left the restriction on the firewall it will still ignore the packets without the specific restrict allowance.