Question re clocking on a serial line - G.703 termination

[d-fillmore]

Hi, I have a customer who has a 2Mb Megastream circuit by BT in the UK.

One end is terminated using X21 and the other end is terminated using 120ohm G.703.

They have an intermittent problem with the circuit whereby it will fine for a few weeks, then they start to see input frame errors at the G.703 end from the output of 'show int'.

'show controllers e1' output was showing a large number of Line Code Violations and Frame Loss Seconds – but only a few Slip Seconds.

These will continue to increment until the circuit becomes unsuable

This is resolved when either the service provider puts a hard loop on the circuit, or the customer physically disconnects the serial cables at both ends and then reconnects them.

The service provider has done extensive tests on the circuit and say there is no fault found.

The service provider says that they are not proving a clock at the G.703 end, yet the interface says it's getting it's clock from the line;

E1 0 is up.

  Applique type is Channelized E1 - balanced

  No alarms detected.

  alarm-trigger is not set

  Version info Firmware: 20040108, FPGA: 11

  Framing is CRC4, Line Code is HDB3, Clock Source is Line.

  Data in current interval (780 seconds elapsed):

     0 Line Code Violations, 0 Path Code Violations

     0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins

     0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs

  Total Data (last 24 hours)

     0 Line Code Violations, 0 Path Code Violations,

     0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins,

     0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs

This output was taken when the circuit is running fine.

Should we configure the clock as internal?

The config for this is very basic;

!

controller E1 0

channel-group 0 timeslots 1-16

!

interface Serial0:0

ip address 10.200.200.1 255.255.255.252

!

To me this looks more like a timing issue of some sort rather than a physical problem with the circuit but I don't know enough about it to be sure.

Any advice greatly appreciated

Cheers, Dom

[Giuseppe Larosa]

Hello Dom,

>> Should we configure the clock as internal?

yes because SP is not providing it

>> The service provider says that they are not proving a clock at the G.703 end, yet the interface says it's getting it's clock from the line

clock source line is default settings and it is good when SP provides clock

the fact that the link starts good and becomes not usable over time is clearly a clock problem

Over time a free running clock will cause errors in the sampling rate/time that will make the receiver considers '0' a '1" just to say

the act of disconnecting or the remote loop done by SP provides a new clean start, but it does not solve the issue

Hope to help

Giuseppe

[d-fillmore]

Hi Giuseppe,

Thanks for your reply,

I set the clocking source to line and left it for a hour, however started seeing increasing frame and crc errors again at a rate of 3%+ of total packets on the serial interface and also getting slip errors on the E1 controller.  So I’ve set it back to line source again and in the last hour the crc/frame errors & slip errors stopped....

Can you think of anything else we can try?

Cheers, Dom

[Giuseppe Larosa · Accepted solution]

Hello Dom,

your test clearly shows you need to take clock from line sorry if I have given misleading information

At least now you can report your findings to the SP.

I think the troubleshooting serial interface of handbook can provide further suggestions

http://www.cisco.com/en/US/docs/internetworking/troubleshooting/guide/tr1915.html#wp1021077

but I'm afraid is focused on V.35 serial interfaces

http://www.cisco.com/en/US/tech/tk713/tk628/technologies_tech_note09186a00800a758d.shtml

A third-option clock source loop-timed is shown for G.703 here:

http://www.cisco.com/en/US/docs/ios/interface/configuration/guide/ir_cfg_ser_if.html#wp1013715

the use of invert TXC I think is for V.35 sync serial

When the board is operating as a DTE, you can invert the TXC clock  signal it gets from the DCE that the DTE uses to transmit data. Invert  the clock signal if the DCE cannot receive SCTE from the DTE, the data  is running at high speeds, and the transmission line is long. Again,  this prevents phase shifting of the data with respect to the clock.

To configure the interface so that the router inverts the TXC clock  signal, use the following command in interface configuration mode.

Command	Purpose
Router(config-if)# dte-invert-txc	Specifies timing configuration to invert TXC clock signal.

The question may be solved with a correct configuration of the DCE device used to convert from V.35 to G.703.

in short: you need a clock from line and the SP has to give you one.

Hope to hellp

Giuseppe

[d-fillmore]

Thank you so much for your help Giuseppe,

I have asked my customer to request the SP provides a clock. If anything positive comes of it I'll post if here for reference

Cheers, Dom