Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Setting Time
- Thread starter g6udx
- Start date
On a 4000M, you do the following:
1. Telnet to the switch.
2. Choose the "Switch Management Access Configuration" option from the menu.
3. Choose the "IP Configuration" option from the menu.
4. Set time sync mode to SNTP
5. Set SNTP mode to Unicast
6. Set "Server Address" to point at a time server on your network--mine points at a windows DC.
7. Save the changes.
I would imagine things are a bit different on a 4108, but the above should be enough to get your started.
1. Telnet to the switch.
2. Choose the "Switch Management Access Configuration" option from the menu.
3. Choose the "IP Configuration" option from the menu.
4. Set time sync mode to SNTP
5. Set SNTP mode to Unicast
6. Set "Server Address" to point at a time server on your network--mine points at a windows DC.
7. Save the changes.
I would imagine things are a bit different on a 4108, but the above should be enough to get your started.
- Thread starter
- #3
Nothing in HP's documentation talks about how time sync is handled in a stack, so I did a little experiment:
I removed one of my switches from a stack.
I removed the SNTP configuration from the switch.
I changed the time on the switch.
I didn't remove the switch's IP address (frankly, I don't want to have to reprogram via serial.)
I rejoined the switch to the stack.
At this point, and after half an hour of observation, the time on the switch remained incorrect. I therefore conclude that you DO have to assign an IP address and setup the SNTP/TIMEP configuration for every switch you want to sync to your time server.
If this presents a problem for one reason or another (lack of address space in subnet, security issues, whatever) you could set up an out of band IP on the stack members, and bind an interface on your time server to an address on the same subnet.
I removed one of my switches from a stack.
I removed the SNTP configuration from the switch.
I changed the time on the switch.
I didn't remove the switch's IP address (frankly, I don't want to have to reprogram via serial.)
I rejoined the switch to the stack.
At this point, and after half an hour of observation, the time on the switch remained incorrect. I therefore conclude that you DO have to assign an IP address and setup the SNTP/TIMEP configuration for every switch you want to sync to your time server.
If this presents a problem for one reason or another (lack of address space in subnet, security issues, whatever) you could set up an out of band IP on the stack members, and bind an interface on your time server to an address on the same subnet.
- Thread starter
- #5
Thanks jkupski
That's pretty much the same as I found, but by a different route.
I know having the wrong time on a switch isn't the end of the world but it can be useful tracking anomolous events sometimes.
Perhaps HP may be planning to look at this at thier next S/W release.
That's pretty much the same as I found, but by a different route.
I know having the wrong time on a switch isn't the end of the world but it can be useful tracking anomolous events sometimes.
Perhaps HP may be planning to look at this at thier next S/W release.
If I may jump in here, is there a difference in using an internal time server (DC) as opposed to using a public time server? I have my switches pointing to the Naval Observatory time servers (192.5.41.209 and 192.5.41.41)
Just wondering,
Joe Brouillette
Just wondering,
Joe Brouillette
Really, the only difference is bandwidth utilization.
Your scenario has every device polling USNO directly--that means more stress on their end, and more of your (limited) internet bandwidth is taken up so your devices can sync their clocks instead of being used for productive work. OTOH, if you configure a single device locally to serve as a time master, and everything syncs to it, it's better for you and better for USNO. You also have the added advantage of only having to make one change should you ever need to find a new time source.
Your scenario has every device polling USNO directly--that means more stress on their end, and more of your (limited) internet bandwidth is taken up so your devices can sync their clocks instead of being used for productive work. OTOH, if you configure a single device locally to serve as a time master, and everything syncs to it, it's better for you and better for USNO. You also have the added advantage of only having to make one change should you ever need to find a new time source.
- Status
Similar threads
- Locked
- Question
- Locked
- Question