[c-nsp] VWIC-2MFT-T1 & VWIC-1MFT-T1 Timing Issues

Jay Hennigan jay at west.net
Thu Mar 23 18:47:40 EST 2006


Clayton Zekelman wrote:
> 
> We have a customer who has 2 T1's between 2 sites.
> 
> At site "A" they have a router with 2 VWIC-1MFT-T1's
> 
> At site "B" they have a router with a VWIC-2MFT-T1
> 
> One of the T1's was installed a few years ago, and was provisioned 
> with HDSL on both ends.
> 
> The second T1 was installed recently, and was provisioned on a fiber 
> mux at site A, and on HDSL at site B.

You need to ask the carrier(s) if they are providing clocking on the
loops.  Generally, carriers don't provide timing on point-to-point
data T1s, but your mileage may vary.  The problem is reaching someone
in $PHONE_COMPANY who has both clue and the permission to talk to
customers.  The T1 that is MUXed down from a T3 is probably clocked
by the carrier.

> The T1's are configured in a Multilink group.
> 
> Site A (VWIC-1MFT-T1) has both T1's set to clock internally, and site 
> B (VWIC-2MFT-T1) is set to derive clock from the incoming line.
> 
> For some strange reason, they're getting errors on the HDSL to HDSL 
> T1, despite the fact that testing from the middle in either on 30 
> minute multi-pattern tests to a CSU loopback shows 100% error free 
> operation.  The H2TU-C's facing site B are also showing 100% clean.

I suspect that the new T-1 has clocking provided by the carrier based
on the errors you're now seeing and the fact that a DS-3 mux is in the
mix.

> I'm suspecting a timing issue. 

Me too.

> I'm wondering if the VWIC-2MFT-T1 
> card is having an issue because the circuit latency is different on 
> the 2 lines. 

Latency is not an issue.  Well, it's not _THIS_ issue.  :-)  The issue 
here is likely that the timing between the two interfaces in each router 
is tied together and it smells like the new T-1 is providing clock.

> Can both T1 ports on this card operate independently 
> with loop derived timing?

Yes, but depending on the routers and the IOS it can be tricky to do.

MFT T1 VWICs are designed to work with TDM voice circuits.  As such 
there are provisions to derive a common network clock for DSPs and
the like.

Here is my suggestion:

Syntax may vary depending on IOS and hardware.

At site B, do the following in global configuration mode:

! First, attempt to clock from the new T1 with the mux.
network-clock-select 1 t1 0/1
! Slot/port should match the new T1
!
!
! If this fails, use internal clock.
network-clock-select 2 system
!
!
! Tell the VWIC-2MFT-T1 to sync with the system.
network-clock-participate wic 0
! or whatever the WIC is.
!


At site A, set both T-1s to loop timing and no network-clock-participate.

What should happen is that (assuming the new T1 is indeed clocked by the 
carrier) it will clock site B which will then clock site A over both T1s 
synchronously.

Should that T1 fail, site B will provide clock (system priority 2) to 
the remaining T1.

Search CCO for references to network-clock-participate and 
network-clock-select for the details and fine print.

-- 
Jay Hennigan - CCIE #7880 - Network Administration - jay at west.net
NetLojix Communications, Inc.  -  http://www.netlojix.com/
WestNet:  Connecting you to the planet.  805 884-6323


More information about the cisco-nsp mailing list