Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Attention: The Community will be in read-only mode on 12/14/2017 from 12:00 am pacific to 11:30 am.

During this time you will only be able to see content. Other interactions such as posting, replying to questions, or marking content as helpful will be disabled for few hours.

We apologize for the inconvenience while we perform important updates to the Community.

New Member

3750 clock

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
Cisco Employee

Re: 3750 clock

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

3 REPLIES
Cisco Employee

Re: 3750 clock

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

Hall of Fame Super Gold

Re: 3750 clock

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.

New Member

Re: 3750 clock

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.

1391
Views
0
Helpful
3
Replies
CreatePlease to create content