cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
340
Views
5
Helpful
4
Replies

Internal Clocking - When is it needed?

mbiadmin2007
Level 1
Level 1

I work for a mid-sized company on Norwalk, CT. Our main office is linked to our 2nd largest office 50 miles away via two bonded P2P T-1 circuits. Both ends are linked via Cisco 2621 routers.

One of the bonded T-1's has, over the past 3 months, started going up and down multiple times (anywhere from 5 to 20 times) every 14-20 days. The time down is anywhere from 45 seconds to 20 minutes. This particular circuit has been in place for close to 7 years and we NEVER had any issues with it.

Now - after going around and around with the provider (AT&T), they are telling us that since it's a P2P circuit, they don't provide any timing on the circuit and we should have the interface at one end set to "internal" and the other end set to "line". I have a Cisco consultant who is very knowledgable and experienced and he thinks they are full of it. Basically - here is what I would like to know:

1) Is it Cisco SOP (Standard Operating Procedure) or Best Practice to enable internal clocking on one end of a P2P circuit?

2) Why would this circuit never have any problems and then all of a sudden we need to set internal clocking? My wory is that AT&T changed a bunch of stuff on their end which caused this and we're having to adapt to compensate - that's fine - until they rectify the problem and we end up with more issues.

3) The biggest issue I have is that if it's best practice or SOP - shouldn;t we enable internal clocking on one side of ALL our P2P circuits? If it's one way or another, great - I just don't like having to do it on one but not on another.

4) Lastly - if this IS something Cisco reccommends, where could I get a copy of that best practice documentation?

Hopefully this is something someone can answer...I'm sure a lot of you hate dealing with telecom providers as much as I do.

1 Accepted Solution

Accepted Solutions

Joe

Perhaps I misinterpreted your question about all circuits. Especially for your other P2P circuits I recognize that you have a difficult choice. I generally adhere to the adage that if it is not broken, then do not fix it/change it. On that basis I would be inclined to let the circuits that are currently working ok go on as they are, but being prepared to configure clocking internal if any of them start to develop instability.

On the other hand I can also see the point that if the provider is not providing clocking then it is likely that at some point they may become unstable and that it might be good to be proactive configure clocking.

HTH

Rick

HTH

Rick

View solution in original post

4 Replies 4

Richard Burts
Hall of Fame
Hall of Fame

Joe

I am not sure that Cisco has a published Best Practice that covers this situation. And if they did have one I suspect that it would say that the Best Practice is to conform to what the provider specifies.

I was quite surprised the first time that I ran into this kind of situation (and did suspect that the provider representative that I was talking to was full of it) but it turned out that configuring that circuit for clocking internal on one end made it work, and not configuring it made the circuit unstable.

I have encountered it several times since then and have concluded that even though I do not understand the logic of when the provider does provide clocking and when they do not, that if they tell me that they are not providing clocking, then I go ahead and configure clocking internal on one side. And that would be my advice to you.

Relative to your first question: I would certainly not advocate configuring clocking internal on every circuit. If it is a circuit where the provider does provide clocking then you want to use it. There is not an "always do it this way" except to always consider what the provider tells you that they are doing for that particular circuit.

Relative to your second question: I do not know why it worked well for so long and then changed. Perhaps AT&T did change something, or perhaps something changed within your own environment.

HTH

Rick

HTH

Rick

Thanks Rick - and to clarify my question about whether I should enable clocking on "all" circuits - I only meant all P2P circuits that the provider states they don't provide timing on - even though I am currently experiencing no issues on any of the other one.

I guess at the end of the day - that's my biggest dillemma - I have 5 other P2P circuits, all through the same provider, and have not had ANY issues at all to date - but at the same time - the provider is telling me that I am lucky and they are NOT providing ay timing on those circuits.

The last thing I want to do is enable internal timing and cause a problem on a circuit that wasn't previously having any problems.

Concurrent with what you said Rick - since enabling internal timing, we haven't seen any problems. This problem happened about every 14-20 days, so another few weeks will need to pss before I am convinced but I do believe this change will be successful.

To sum up what I'm really looking for is:

Do I enable internal timing on the rest of my P2P circuits that the provider doesn't provide timing for, even though we are experiencing no issues with them, or do we wait for an issue to arise and only enable internal timing at that point? To go one step further - moving forward, if we incorporate any more P2P circuits (with no provided-timing) - do we enable internal timing from the get-go or not?

Much appreciated for your reply Rick.

Joe

Perhaps I misinterpreted your question about all circuits. Especially for your other P2P circuits I recognize that you have a difficult choice. I generally adhere to the adage that if it is not broken, then do not fix it/change it. On that basis I would be inclined to let the circuits that are currently working ok go on as they are, but being prepared to configure clocking internal if any of them start to develop instability.

On the other hand I can also see the point that if the provider is not providing clocking then it is likely that at some point they may become unstable and that it might be good to be proactive configure clocking.

HTH

Rick

HTH

Rick

That sounds like the best policy moving forward Rick. At the very least - this was a learning experience for me and my team.

Many thanks again for your reply and willingness to share information. I truly appreciate it.

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: