Telmex E1

Unanswered Question
Feb 26th, 2008

We're attempting to bring up a point-to-point connection E1 to T1 from Telmex. We are using 1841 routers on both ends with a WIC-1T (V.35 cable) to a Watson NTU/DSU. The Serial interface is up. But the line protocol is down.

On router A:

interface Serial0/0/0

bandwidth 1536

ip address x.X.X.X 255.255.255.252

encapsulation ppp

On router B:

interface Serial0/0/0

bandwidth 1536

ip address x.x.x.x 255.255.255.252

encapsulation ppp

I have tried HDLC encapsulation, and other configs without success.

Telmex is literally refusing to tell us exactly how the line is provisioned so that we may configure the routers correctly.

Any help would be appreciated.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (2 ratings)
Loading.
aijaz802 Tue, 02/26/2008 - 06:03

Hi,

AFAIK you should configure the bandwidth/line speed settings in the NTU/DSU. In NTU/DSU there is option to set the required speed in ur case I think it is 1536/1544.

You didn't mention whether you configure r not. The bandwidth command on the serial interface is use full for the dynamic routing protocols to calculate the path cost.

Rate if it helps..

BR

*aijaz*

blamb Tue, 02/26/2008 - 07:02

Telmex is managing the NTU. I did just get them to send me screen shots of the NTU's config. The settings: SHDSL, framed, bitrate is set to 24x64=1536 kbit/s, linerate is set to 16=1032 kbit/s, timing is contradirectional, CRC4 is off, AIS Gen on, AIS detection is on, timing is recover from E1

blamb Wed, 02/27/2008 - 05:52

After working with Telmex, the NTU is configured, but now the line protocol on the serial interfaces on both ends come up and go down repeatedly.

blamb Wed, 02/27/2008 - 13:57

We aren't using controller E1 in this config. We are using the WIC-1T with an external DSU(NTU) - so there's just the serial interface. Here is the output of "show controllers serial0/0/0." We are encapsulating ppp on both sides.

Interface Serial0/0/0

Hardware is GT96K

DTE V.35 TX and RX clocks detected.

idb at 0x64CF806C, driver data structure at 0x64CFF778

wic_info 0x64CFFDA4

Physical Port 0, SCC Num 0

MPSC Registers:

MMCR_L=0x000304C0, MMCR_H=0x00000000, MPCR=0x00000000

CHR1=0x00FE007E, CHR2=0x00000000, CHR3=0x0000064A, CHR4=0x00000000

CHR5=0x00000000, CHR6=0x00000000, CHR7=0x00000000, CHR8=0x00000000

CHR9=0x00000000, CHR10=0x00000828

SDMA Registers:

SDC=0x00002201, SDCM=0x00000080, SGC=0x0000C000

CRDP=0x078BF0A0, CTDP=0x078BF2E0, FTDB=0x078BF2E0

Main Routing Register=0x0003FFF8 BRG Conf Register=0x00490013

Rx Clk Routing Register=0x76543218 Tx Clk Routing Register=0x76543219

GPP Registers:

Conf=0x30002 , Io=0x64050 , Data=0x7F3BBFA9, Level=0x180000

Conf0=0x30002 , Io0=0x64050 , Data0=0x7F5BBFA9, Level0=0x180000

9293827 input aborts on receiving flag sequence

0 throttles, 0 enables

2968727 overruns

0 transmitter underruns

0 transmitter CTS losts

12407539 rxintr, 74547 txintr, 0 rxerr, 0 txerr

30811814 mpsc_rx, 0 mpsc_rxerr, 253538 mpsc_rlsc, 6930966 mpsc_rhnt, 24272299 mpsc_rfsc

9098 mpsc_rcsc, 0 mpsc_rovr, 0 mpsc_rcdl, 0 mpsc_rckg, 0 mpsc_bper

0 mpsc_txerr, 39284 mpsc_teidl, 0 mpsc_tudr, 0 mpsc_tctsl, 0 mpsc_tckg

0 sdma_rx_sf, 2 sdma_rx_mfl, 2968727 sdma_rx_or, 9293827 sdma_rx_abr, 5304611 sdma_rx_no

0 sdma_rx_de, 0 sdma_rx_cdl, 12397004 sdma_rx_ce, 0 sdma_tx_rl, 0 sdma_tx_ur, 0 sdma_tx_ctsl

0 sdma_rx_reserr, 0 sdma_tx_reserr

0 rx_bogus_pkts, rx_bogus_flag FALSE

0 sdma_tx_ur_processed

tx_limited = 1(2), errata19 count1 - 0, count2 - 0

Receive Ring

rxr head (0)(0x078BF0A0), rxr tail (0)(0x078BF0A0)

rmd(78BF0A0): nbd 78BF0B0 cmd_sts 80800000 buf_sz 06000000 buf_ptr 78CAE00

rmd(78BF0B0): nbd 78BF0C0 cmd_sts 80800000 buf_sz 06000000 buf_ptr 78C3B40

rmd(78BF0C0): nbd 78BF0D0 cmd_sts 80800000 buf_sz 06000000 buf_ptr 78C0EA0

rmd(78BF0D0): nbd 78BF0E0 cmd_sts 80800000 buf_sz 06000000 buf_ptr 78C7B00

rmd(78BF0E0): nbd 78BF0F0 cmd_sts 80800000 buf_sz 06000000 buf_ptr 78CCDE0

rmd(78BF0F0): nbd 78BF100 cmd_sts 80800000 buf_sz 06000000 buf_ptr 78CA140

rmd(78BF100): nbd 78BF110 cmd_sts 80800000 buf_sz 06000000 buf_ptr 78C01E0

rmd(78BF110): nbd 78BF120 cmd_sts 80800000 buf_sz 06000000 buf_ptr 78C34E0

rmd(78BF120): nbd 78BF130 cmd_sts 80800000 buf_sz 06000000 buf_ptr 78CC780

rmd(78BF130): nbd 78BF140 cmd_sts 80800000 buf_sz 06000000 buf_ptr 78CC120

rmd(78BF140): nbd 78BF150 cmd_sts 80800000 buf_sz 06000000 buf_ptr 78C8E20

rmd(78BF150): nbd 78BF160 cmd_sts 80800000 buf_sz 06000000 buf_ptr 78C1500

rmd(78BF160): nbd 78BF170 cmd_sts 80800000 buf_sz 06000000 buf_ptr 78C9480

rmd(78BF170): nbd 78BF180 cmd_sts 80800000 buf_sz 06000000 buf_ptr 78C4E60

rmd(78BF180): nbd 78BF190 cmd_sts 80800000 buf_sz 06000000 buf_ptr 78C0840

rmd(78BF190): nbd 78BF1A0 cmd_sts 80800000 buf_sz 06000000 buf_ptr 78C67E0

rmd(78BF1A0): nbd 78BF1B0 cmd_sts 80800000 buf_sz 06000000 buf_ptr 78C1B60

rmd(78BF1B0): nbd 78BF1C0 cmd_sts 80800000 buf_sz 06000000 buf_ptr 78C87C0

rmd(78BF1C0): nbd 78BF1D0 cmd_sts 80800000 buf_sz 06000000 buf_ptr 78C2820

rmd(78BF1D0): nbd 78BF1E0 cmd_sts 80800000 buf_sz 06000000 buf_ptr 78C8160

rmd(78BF1E0): nbd 78BF1F0 cmd_sts 80800000 buf_sz 06000000 buf_ptr 78CBAC0

rmd(78BF1F0): nbd 78BF200 cmd_sts 80800000 buf_sz 06000000 buf_ptr 78C4800

rmd(78BF200): nbd 78BF210 cmd_sts 80800000 buf_sz 06000000 buf_ptr 78BFB80

rmd(78BF210): nbd 78BF220 cmd_sts 80800000 buf_sz 06000000 buf_ptr 78C21C0

rmd(78BF220): nbd 78BF230 cmd_sts 80800000

Paolo Bevilacqua Wed, 02/27/2008 - 14:07

Hi, not using a native E1 interface will prevent you from seeing the real circuit performance and status in the router, in other words, telco can tell you anything, but you will have little tools to see by yourself.

Anyway, the interface seems to be severely affected by errors. Do "clear counters", wait some minutes, the collect and send "show interface s0/0/0".

If anything fails, tell telco to connect their test tools to the NTU (that they are probably charging for), and prove the circuit is working at V.35 level.

If they won't or can't, you best chance is getting T1 and E1 interfaces in the router (I can provide the P/N if you need), and if the TDM guys do know a little what they're doing, you will be up and running.

blamb Thu, 02/28/2008 - 06:35

Yes, you're correct. We are at the mercy of the telco because we can't see what's occuring on the circuit. We used the router and WIC that the telco recommended. That was a mistake. We will probably go back and get the better interface. Perhaps the VWIC2-MFT-E1. Which one is the best for this type of border-crossing connection? We were able to track the problem back to the E1 to T1 conversion. Loopbacks at key points up and down the line revealed the location of the problem. The US telco is doing the conversion and said the standard E1 to T1 conversion ports channel 16 of the T1 to channel 31 of the E1 to forward the framing. But the MX telco seems to have limited the channels down to 24 to match the T1 channels. We are still working with both telcos to get them to re-provision the line correctly. That is what we have learned so far. If anyone has more insight, I could use it.

Paolo Bevilacqua Thu, 02/28/2008 - 06:42

Hi,

both VWIC and VWIC2 cards are ok for that.

But, you're saying that timeslot 16 on T1 has been mapped to 31 on the E1 side.

This is likely to cause the problem, because it puts timeslots on E1 out of sequence, and as you noted, using 31 whereas the mexico has the upper timeslot as 24.

If you was to use the VWIC card, you could have avoided using the troublesome timeslot and kind of fixed things yourself.

Anyway, have them leave T1 TS 16 mapped to E1 TS 16, and chances are you'll be OK.

blamb Thu, 02/28/2008 - 07:51

Thank you all. The US telco that is actually doing the conversion claims that porting channel 16 to channel 31 is part of the standard T1 to E1 conversion setup. But I agree, getting them to leave the 16 to 16 may be what we need. But I'm not familiar with standard practices in the setup. I'm working now to get them tomake the changes

Paolo Bevilacqua Thu, 02/28/2008 - 08:06

There is no standard practice.

If that was a PRI connection, it would make sense to map T1 TS 24 to E1 TS 16.

But I've never heard of TS 16 to 31. Data circuits in E1 world, do use TS16 all the time.

If you can't have the correct mapping done, or still unsure about it, have the NTUs on both sides set to skip TS 16 altogether. This may leave you with a 64 kbps x 23 circuit, still better than the junk the router sees now.

blamb Wed, 03/05/2008 - 14:03

Closing update,

As it turns out, the channels on the E1 side of the connection were not setup correctly. Despite the telcos claim. Not entirely surprising, I know. Mental note - get the VWIC modules next time.

Paolo Bevilacqua Wed, 03/05/2008 - 15:25

May be a chance for the T1 guys to learn a bit about E1 :)

Thanks for the nice rating and good luck!

Actions

This Discussion