04-18-2014 04:57 PM - edited 03-11-2019 09:06 PM
Hi Everyone,
Here is setup
switch ---ASA---ISP
NTP is working find on ASA.
ASA1# sh ntp status
Clock is synchronized, stratum 3, reference is 128.100.56.135
nominal freq is 99.9984 Hz, actual freq is 99.9722 Hz, precision is 2**6
reference time is d6fc38f2.4f6dc3e8 (17:51:14.310 MST Fri Apr 18 2014)
clock offset is 0.8270 msec, root delay is 52.44 msec
root dispersion is 18.30 msec, peer dispersion is 17.47 msec
Switch is connected via vlan 1 to ASA on inside interface.
Config on switch
ntp source Vlan1
ntp server 10.0.0.1
From switch i can ping internet fine.
Switch#ping 4.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 75/80/84 ms
Switch#ping 10.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
Switch has default gateway 10.0.0.1 which is IP of ASA outside interface.
Switch#sh ntp status
Clock is unsynchronized, stratum 16, no reference clock
nominal freq is 119.2092 Hz, actual freq is 119.2072 Hz, precision is 2**18
reference time is D6F449A1.5A28B6E4 (17:24:17.352 MST Sat Apr 12 2014)
clock offset is -4.6788 msec, root delay is 50.17 msec
I changed NTP server on Switch to 128.100.56.135 still NTP does not work.
ASA inside interface has ACL permit ip any any.
Regards
MAhesh
Solved! Go to Solution.
04-18-2014 09:04 PM
Mahesh,
You mention the switch gateway is the outside of the ASA but with a private address. If the switch source address is in 10.0.0.0/x network it will never reach a public NTP server without a NAT policy somewhere.
Do you have a NAT policy that would include the switch source address?The ASA we would expect to work since its source for the public NTP server is its outside interface. The switch would only work (given the permit ip any any acl you mention) if there is also a nat to give the queries a public IP address as they leave the ASA.
You can easily check the flow using packet-tracer:
packet tracer input inside udp <switch address> 1024 128.100.56.135 123
That will tell you what the ASA will do when presented with an ntp (udp/123) request destined for the NTP server you are using.
04-19-2014 06:28 AM
I have done it both ways - synchronize to a public NTP server or only have one internal device synchronize to public and then use it as the internal NTP source.
One can make an argument in favor of either technique. My opinion is that as long as you are using NTP everywhere and have things like "service timestamps" on your log messages you are already doing very well and are n the best practices realm with regards to timekeeping on your network.
If you really want to spend a lot of time on it, you can read the Cisco Whitepaper on NTP Best Practices.
04-18-2014 09:04 PM
Mahesh,
You mention the switch gateway is the outside of the ASA but with a private address. If the switch source address is in 10.0.0.0/x network it will never reach a public NTP server without a NAT policy somewhere.
Do you have a NAT policy that would include the switch source address?The ASA we would expect to work since its source for the public NTP server is its outside interface. The switch would only work (given the permit ip any any acl you mention) if there is also a nat to give the queries a public IP address as they leave the ASA.
You can easily check the flow using packet-tracer:
packet tracer input inside udp <switch address> 1024 128.100.56.135 123
That will tell you what the ASA will do when presented with an ntp (udp/123) request destined for the NTP server you are using.
04-18-2014 10:12 PM
Hi Marvin,
Here is packet tracer output
ASA1# packet-tracer input inside udp 10.0.0.2 1024 128.100.$
Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list
Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 0.0.0.0 0.0.0.0 outside
Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group inside_access_in in interface inside
access-list inside_access_in extended permit ip any any
Additional Information:
Phase: 4
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside,outside) source dynamic inside interface
Additional Information:
Dynamic translate 10.0.0.2/1024 to 96.51.149.178/57056
Phase: 5
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
Phase: 6
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 7
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (inside,outside) source dynamic inside interface
Additional Information:
Phase: 8
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
Phase: 9
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 10
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 215401, packet dispatched to next module
Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow
Regards
MAhesh
04-18-2014 10:24 PM
Hi Marvin,
i changed the NTP server to 128.x.x.x
sh ntp status
Clock is synchronized, stratum 3, reference is 128.100.56.135
nominal freq is 119.2092 Hz, actual freq is 119.2072 Hz, precision is 2**18
reference time is D6FC852A.800B5C28 (23:16:26.500 MST Fri Apr 18 2014)
clock offset is 12.0771 msec, root delay is 53.92 msec
root dispersion is 13.29 msec, peer dispersion is 1.22 msec
Surprised it work now.Earlier it was not.
So one thing to confirm if we have any Network device which is behind the inside interface of ASA and if it needs NTP then we should use the Public NTP servers instead of switch or routers gateway?
Regards
MAhesh
04-19-2014 06:28 AM
I have done it both ways - synchronize to a public NTP server or only have one internal device synchronize to public and then use it as the internal NTP source.
One can make an argument in favor of either technique. My opinion is that as long as you are using NTP everywhere and have things like "service timestamps" on your log messages you are already doing very well and are n the best practices realm with regards to timekeeping on your network.
If you really want to spend a lot of time on it, you can read the Cisco Whitepaper on NTP Best Practices.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide