02-26-2008 05:35 AM - edited 03-03-2019 08:52 PM
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.
02-26-2008 06:03 AM
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*
02-26-2008 07:02 AM
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
02-27-2008 05:52 AM
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.
02-27-2008 10:22 AM
Please send output of "show controllers e1". Are you using same encap on both sides ?
02-27-2008 01:57 PM
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
02-27-2008 02:07 PM
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.
02-28-2008 06:35 AM
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.
02-28-2008 06:42 AM
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.
02-28-2008 07:51 AM
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
02-28-2008 08:06 AM
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.
03-05-2008 02:03 PM
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.
03-05-2008 03:25 PM
May be a chance for the T1 guys to learn a bit about E1 :)
Thanks for the nice rating and good luck!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide