15454 Timing Question

[joemarr_brodart]

I currently have 2 nodes connected via single OC48 (used to carry 2 gige circuits). Node 1 uses the internal clock for timing, Node 2 is looking to the line for timing. Currently this config seems to work fine. Now i need to bring up a second oc48 from another vendor. I had hoped to simply follow this same config, however I appear some sort of timing issue as I cannot bring up a DCC over the circuit and the vendor says they see a loss of pointer. I currently dont have a bits source availible as I plan on eliminating the ONS gear in a couple of months. Would anyone be able to help me understand what I need todo to bring this second circuit online?

[Marvin Rhoads]

Caveat - running a network solely from one node's internal timing is not a recommended configuration.

Can you post your timing configuration for node 1? (CTC Maintenance > Timing > Reports). I ask to confirm that you have followed Procedure "DLP-A70 Set Up Internal Timing"

What sort of OC-48 card(s) are you using? Could you perhaps be running into the limitation that only one port of a multi-port optical card can be provisioned as a timing reference?

[viyuan700]

Since you are using internal timing, are these nodes are connected back to back without any circuit from service provider.

It is possible that instead of timing problem the Loss of Pointer (LOP) is due to some misconfiguration maybe cisco have some default setting and other vendor have something else for the same parameter.

see this link the problem for LOP is misconfiguration though it is for juniper but can help you to figure out the problem i think (you can chcek other parameters too)

http://www.juniper.net/techpubs/software/nog/nog-interfaces/html/sonet-alarms220.html

[Tom Randstrom]

Any luck getting this resolved?

LOP is probably a provisioning issue between you and your carrier. Need to make sure the circuits match between you and your carrier.

The DCC issue could be the result of incompatible DCC protocols (IP on 15454 and OSI on carrier equipment). Make sure you set-up the 15454s to match your carrier's equipment.

[tphelps]

You currently have two different topologies as far as timing is concerned.

In the first scenario, you have two nodes directly connected with fiber (I assume). The first node is acting as the timing source running Internal timing (ST3) and the second nodes synchs to the first. While the quality is less than stellar, at least the nodes are in sync. Stratum 3 is the minimum SONET quality. As long as the sync is stable, it works.

Node 1 (Internal ST3) ----- OC48 ----- Node 2 (LINE ST3 traceable)

In the second scenario, you have a similar but different case because the second node is managed by another entity. I would ask the provider if their OC48 node has a timing connection or ST1 traceable timing at the least. Most likely they do. If so, I would LINE time my node(s) from the carrier. Running your Node 1 on INTERNAL and the carrier node on whatever timing source will likely become out-of-sync and result in errors. Pointer errors typically happen because the floating payload can only offset so far to accommodate out-of-sync timing.

SONET. The 'S' is important. Synch is just as - if not more - important than quality.

As for the DCC issue, DCC's are provisioned per span and MOST carriers do not enable DCC on customer interfaces (security risk). This is why you do not get the end-to-end DCC. You will have to use Server Trails to get A-Z provisioning or use good ole mid-span meet. Create circuits to matching resources on either end and they will meet in the middle.

For example…

Node 1, Circuit 1: GE to Slot 6/Port 1/STS3

Node 2, Circuit 1: GE to Slot 12/Port 1/STS3

The circuit will meet on STS3 over the OC48

If the OC48 is provided by a carrier, find out what types of circuits are provisioned in their OC48 (1x STS48c, 48x STS1, etc.). You will have to match the circuit size.