cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2323
Views
0
Helpful
3
Replies

3750 clock

OSNAFBCCO
Level 1
Level 1

We have several 3750G-48PS switches that we recently configured as stub routers for some buildings identified as mission-critical. This decision was made to enable the simultaneous utilization of the redundant uplinks. It is also a requirement that we use keys to authenticate routing updates so we have a key chain configured with two 6-month keys and a backup infinite key. The infinite key has an earliest possible date of something like the year 2000 however, one of the switches lost power and when it booted it started with a system date of something like 1996. Thus, we encountered a paradox: the 3750 could not recieve routing updates as none of the keys can possibly be valid (including the backup infinite key) due to the time being wrong and the time cannot be updated via NTP because no routing updates could be recieved. We had this issue several months ago with some 3745 routers which we fixed with the command "clock save interval" but this command appears to be unrecognized by a 3750 (IOS 12.2(53)SE). As the 3750 does not have support for a hardware clock or calendar the alternative, (which is available on our 6500s) "ntp update-calendar", is also not available. The command "clock save interval" was supposedly introduced in 12.2SRA and 12.2SX but neither of those IOS trains are available for a 3750.

Is there any recourse, other than removing the routing authentication, which will prevent this situation from occurring in the future? Any help is appreciated.

1 Accepted Solution

Accepted Solutions

Nagaraja Thanthry
Cisco Employee
Cisco Employee

Hello,

As of now, lower end catalyst switches cannot save the clock information internally. So, everytime they reboot, their clock will be reset back to the original date. However, in your case, you could add a static route on the switch towards the NTP server. This will ensure that the switch knows how to update its clock from the NTP server. Once the clock is updated, all your keys will be valid and you should not have any issues with routing.

Hope this helps.

Regards,

NT

View solution in original post

3 Replies 3

Nagaraja Thanthry
Cisco Employee
Cisco Employee

Hello,

As of now, lower end catalyst switches cannot save the clock information internally. So, everytime they reboot, their clock will be reset back to the original date. However, in your case, you could add a static route on the switch towards the NTP server. This will ensure that the switch knows how to update its clock from the NTP server. Once the clock is updated, all your keys will be valid and you should not have any issues with routing.

Hope this helps.

Regards,

NT

Leo Laohoo
Hall of Fame
Hall of Fame

I wouldn't configure Cisco appliance as an authoritative NTP server.

If you have Windows servers, you can configure them to be an authoritative NTP server.

How to configure an authoritative time server in Windows XP
http://support.microsoft.com/kb/314054

How to configure an authoritative time server in Windows Server
http://support.microsoft.com/kb/816042

How to configure an authoritative time server in Windows 2000
http://support.microsoft.com/kb/216734

Otherwise, use a dedicated NTP server that synchronizes itself using GPS.  The reason why I don't recommend a Cisco appliance as an authoritative NTP/SNTP server is because the clock chip is similar to a PC.  It doesn't have a dedicated method of verifying.  You can get a cheap NTP server that uses GPS (best method so far).  Another option is to open a port in the firewall to allow the device(s) to talk to world-wide NTP pool.

OSNAFBCCO
Level 1
Level 1

Thanks for the input. We already have an NTP server so there is no need to configure one. The problem with NTP is the traffic to and from the loopback only works once the routing protocol causes the switch exchange routes with the neighboring routers. So, the problem with getting the authentication working relies on a functional route to the loopback of the switch and a route to the NTP server from the switch.

We fixed this by adding static routes on all of the directly connected routers but made the administrative distance 130 so that it will only have priority if no IGP route is available. We then added the static default routes into the 3750 switches (which we had previously removed due to a summary route being supplied by the neighboring routers) with the same administrative distance of 130 for the same reason. This way, NTP packets will travel to and from the loopback and once the time is updated the routing authentication will succeed.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: