We are designing a small private network with a hub Atlas 550 and some remote Atlas 550s.
At one of the remote Atlas 550s, we would like to digitally hand off some DS0s onto a T1 owned by another company and they will route it a few more hops to our endpoint which is on their network. (All E&M)
I noticed when bench testing two 550s that if one is not getting its timing from the other then they will lose connection pretty regularly.
Our network will probably have the hub 550 as the primary timing source. The network we are handing off to will have its own timing source.
Is it possible to directly hand DS0's from one to the other digitally?
In principle I would hate to convert this to analog E&M, run 4 feet and then go back to digital again but it would not be the end of the world.
What you described is known as "clock slips." If both ATLAS are configured for INTERNAL clocking, then their clocks will be off a little bit, and at a regular interval they will drift far enough to have a clock slip and frame slip, then be back in sync until the next slip.
The ATLAS only supports one clock source, so if a T1 has clocking on it, then you should set the ATLAS to take clock from that T1. You can always set the BACKUP timing to be INTERNAL at the hub, so if the T1 with timing goes down, the hub will revert to INTERNAL timing to provide clock for the other circuits. All the "spoke" ATLI will still take clock from the T1s coming from the hub.
Hope this makes sense,
Patrick
The term clock slip makes perfect sense.
The spoke 550 will be handing off to a foreign network that has its own clock source further down the line.
So set this particular spoke 550 to take clock from the foreign network primary and take clock from the hub 550 secondary.
Set the hub 550 to take clock from this spoke 550 primary and internal secondary. Then if the foreign network goes down we don't lose much.
All other spoke 550s get their clock from the hub.
It sounds a little hokey but I guess it should work.
Please tell me if I'm understanding correctly?
-------------
Furthermore I tried it with both clocks internal to listen to it slip and see how it sounds. Sending a 1 KHz tone through it.
I can tell when the clock slip occurs because there is a little blip in the audio but other than that, it sounds fine.
Is this a reliable way to run a network should it come to this? With the clock slipping all the time? I don't really like how the warning lights are constantly flashing.
I have a stack of 3 Atlas 550s on the bench to simulate this configuration.
One is the Hub set to get its timing from the Spoke or internally if unavailable.
One is the Spoke set to get its timing from the Foreign network primarily and from the Hub secondarily.
One is the Foreign network generating its own timing internally.
Boot everything up and it all works OK. But unplug the Foreign from the Spoke and plug it back in and it will never reestablish a connection. It just sits there in ALARM or sometimes TEST.
Funny thing is, listening to the output audio if you unplug the
If you reboot either the Spoke or the Foreign it all comes back to life again.
After further experimentation, if I reverse the FROM and TO on the intermediate router map (which is passing a single DS0 from one T1 to the other) it fixes the above mentioned problem.
What it does not fix is that the timing source will switch to the backup (T1 line to the hub) and never revert to the primary (T1 line to the foreign network). So there is a constant clock slip going on.
How can I make the timing source go back to primary?
If the backup timing source is an interface, and not INTERNAL, then the ATLAS will not automatically switch back to the primary. To force it to switch back to the primary the secondary has to go into alarm, or lose clock, or you can set the BACKUP to INTERNAL and after it switches to the primary, change the backup to the desired interface again.
So if the ATLAS switches to the backup timing source, it will only switch back to the primary automatically if the backup is internal, or if the backup goes down.