Tag Archives: cisco

NTP on the 6509

1 Reply

Had some minor drama with the core switch clock being out by well over an hour. Not causing any issue except frustration when viewing logs and trying to compare timestamps across devices.

All the network devices get their time sync from the wan router (which in turn contacts our ntp server for its time).

To fix it up – remove all the ntp related statements from the cisco 6509, then manually set the clock to within 5 mins of the actual time as reported by the ntp server, then re-apply the ‘ntp server’ statement(s). After a short while the clock will re-sync correctly with the ntp server specified.

Never apply the ‘ntp clock-period’ statement – this is done by the device itself. I think someone manually applied this and that was why the time started to get way out.
ie. Make sure you never copy the ‘ntp clock-period’ statement from one device to another. The clock-period is set by NTP; to regulate the internal clock on the device. This is the number of ticks in one second. Therefore, NTP doesn’t change the time of the switch, it adjusts the clock-period so that the system clock is synchronized with the ntp server.

No luck so far with the ACE log issue

1 Reply

I’ve sent more info to the TAC re that ACE logging issue – which has not shown up again for a few weeks. It stopped suddenly after the production rservers in the ‘correct’ context were finally started up (the context was prepared and active prior to server deployment). In any case, the TAC has escalated it to the engineering team for analysis. I agreed with one of Cisco’s engineers that said “this shouldn’t be possible”. Love it :)

We deployed a Cisco WAAS appliance to the Brisbane office – all seemed ok however the voice team said ‘at some stage after the WAAS was turned on’ they had messages-on-hold errors. Strange given that WAN optimisers ignore udp. Because the deployment is using wccp – it is likely something has gone wrong with the router – or it could be unrelated altogether.

Also, I learned a valuable lesson the other night – never gloss over the ‘clear xlate’ command on a FWSM. When messing around with static nats, hours can be saved troubleshooting by using that command … bah.

Riverbed vs WAAS … part one

4 Replies

I’ve been re-visiting the whole Riverbed vs Cisco WAAS situation again. We have a few WAAS appliances and modules in production, and they do the job – for now. I am concerned about the scalability of their solution and it is my opinion that Riverbed has the edge here and in other areas – except price. I’m not one to really care about price usually because I am more concerned with the outcome – but sure it is a consideration for the business. Hence, I’ve gone back to have a look at it all again.

Watch the Riverbed video here

It is impressive stuff. Cisco has the edge on price – but not much else. Riverbed is a clear winner when it comes to ease of deployment, scalability and technology. I’ll come back and justify my comments with some data soon.