We've had a few mentions how cheap home routers with nat state can fail under pool ntp load, but this isn't limited to 'cheap'.
Our network was migrated from a filtering router to a cisco fwsm (firewall
services module) which has several virtual firewalls. Our dmz, hosting
ntp.cs.uu.nl is in one context and I have limited rights to see stats for
that firewall context.
After a while the entire university network became 'unstable'. Not all
connections would go through in very unpredictable ways.
It took a while to find out the cause: the cisco fwsm keeps NAT state even
for connections which don't actually use NAT. This state is named 'xlates'.
The statistics for xlates showed absurdly high numbers in use, which
matches ntp traffic (1200 different IPs requesting service in one second
isn't a DOS attack, it's normal). And in our firewall setup, there is no
per-context limit on xlates, so our ntp traffic was influencing the entire
firewall.
When I made the connection between the high number of xlates and ntp
traffic I downgraded our ntp pool server to a lower network speed.
Reading the documentation showed that 'xlate-bypass' should do the trick:
not maintain xlate state for connections without NAT.
So I requested this change. Forward several months of discussion about the
change and delays it was implemented today. I directly set our pool speed
back to the real speed (gigabit) and awaited the first flood of ntp
requests which just came by and was not visible in the xlate state
graph.
So, if your ntp server is behind a cisco fwsm: 'xlate-bypass' will do the
trick.
Koos
--
Koos van den Hout, herding systems and networks as [email protected]
+31-30-2534104 PGP keyid 0x27513781
http://idefix.net/~koos/ Use PGP when possible!
Visit my site about books with reviews http://www.virtualbookcase.com/
pgp7xKaZ9zLyk.pgp
Description: PGP signature
_______________________________________________ timekeepers mailing list [email protected] https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
