From: William Walla (wwalla@gmail.com)
Date: Fri Sep 01 2006 - 17:43:29 ART
Thanks Guys! This group rocks!!
Trying to get them to account and fix the issue has been trying.
The cable length and
lbo command fixed it!!!
On 9/1/06, Sean C <Upp_and_Upp@hotmail.com> wrote:
>
> I really can't comment on the controllers output. Not sure how to
> interpret the results. Have you started a TAC case? They usually can give
> some insight. I'm assuming that you have replaced the cable from the
> carrier's dmarc to your equipment if you're onsite today.
>
> Concerning the "intrusive test" you mentioned at the bottom of your email,
> sounds like the carrier just did a remote test from their CO to your
> SmartJack. I'd keep demanding a LEC dispatch - don't be afraid to expedite
> your request. Until the carrier can prove through their dmarc, I wouldn't
> be satisfied. A typical remote test can only test up through the card in
> the SmartJack, the remote test can't verify through to the RJ-45 port which
> is after the card in the SmartJack. The female RJ-45 port is where the real
> demarcation between the carrier and your equipment is typically defined.
>
>
> Good luck!
> Sean
>
> ----- Original Message -----
> *From:* William Walla <wwalla@gmail.com>
> *To:* Sean C. <Upp_and_Upp@hotmail.com>
> *Cc:* Cisco certification <ccielab@groupstudy.com>
> *Sent:* Friday, September 01, 2006 11:22 AM
> *Subject:* Re: OT ATM card issues
>
>
>
>
>
>
>
> here is the sh controllers output after I have just reseated the card and
> reload the 3825. Teloc is dragging there feet and did not finish their
> testing yet!
>
> What are the errors that are telling from this output?
>
> thanks!
>
>
> ce-01#sh controllers atm1/0
> Interface ATM1/0 is up
> Hardware is RS8234 ATM DS3
> LANE client MAC address is 0013.60c7.2730
> hwidb=0x65AF48C8, ds=0x65AF6178
> RS8234 base 4A000000, ds 65AF6178, PM5346 base 4A400000, slave base
> 4A400000
> SBDs - avail 2048, guaranteed 1, unguaranteed 2047, starved 0 rbds 4098
> Seg VCC SCH access timeout 0
> Seg VCC table 4A00DD80, Shadow Seg VCC Table 65B2234C, VCD Table 65B38378
> Schedule table 4A018D80, Shadow Schedule table 65B3F3A4, Size FC1
> RSM VCC Table 4A14F180, Shadow RSM VCC Table 65C46D58
> VPI Index Table 4A04C700, VCI Index Table 4A04F180
> Bucket2 Table 4A02C900, Shadow Bucket2 Table 65B432D4
> MCR Limit Table 4A02CD00, Shadow MCR Table 65B44F00
> ABR template 4A02CF00, Shadow template 64A66384
> RM Cell RS Queue 4A04D180
> RBD OIR array 65AF8EF0, HBD OIR array 65AF6EF0
> LECID Table 4A04CF00, Host LECID Table 65AFD8C0, LECID Table Bitmask 0
> Queue TXQ Addr Pos StQ Addr Pos
> 0 UBR 4A048F00 0 2E5C1040 0
> 1 UBR PLUS 4A049300 0 2E5C1840 0
> 2 UBR TUN1 4A049700 0 2E5C2040 0
> 3 UBR TUN2 4A049B00 0 2E5C2840 0
> 4 UBR TUN3 4A049F00 0 2E5C3040 0
> 5 ABR 4A04A300 0 2E5C3840 0
> 6 VBR NRT 4A04A700 211 2E5C4040 211
> 7 VBR RT 4A04AB00 0 2E5C4840 0
> 8 VBR/ABR TUN1 4A04AF00 0 2E5C5040 0
> 9 VBR/ABR TUN2 4A04B300 0 2E5C5840 0
> 10 VBR/ABR TUN3 4A04B700 0 2E5C6040 0
> 11 SIG 4A04BB00 0 2E5C6840 0
> 12 CBR 4A04BF00 0 2E5C7040 0
> 13 VPD 4A04C300 0 2E5C7840 0
>
> Queue FBQ Addr Pos RSQ Addr Pos
> 0 OAM 4A15B180 239 2E5C8080 240
> 1 UBR 4A15C180 0 2E5C9080 0
> 2 UBR PLUS 4A15D180 0 2E5CA080 0
> 3 UBR TUN1 4A15E180 0 2E5CB080 0
> 4 UBR TUN2 4A15F180 0 2E5CC080 0
> 5 UBR TUN3 4A160180 0 2E5CD080 0
> 6 ABR 4A161180 0 2E5CE080 0
> 7 VBR NRT 4A162180 32 2E5CF080 173
> 8 VBR RT 4A163180 0 2E5D0080 0
> 9 VBR/ABR TUN1 4A164180 0 2E5D1080 0
> 10 VBR/ABR TUN2 4A165180 0 2E5D2080 0
> 11 VBR/ABR TUN3 4A166180 0 2E5D3080 0
> 12 SIG 4A167180 0 2E5D4080 0
> 13 CBR 4A168180 0 2E5D5080 0
>
> PCI bus err 0, DMA fifo full err 0, RSM parity err 0
> RSM sync err 0, RSM/SEG Q full err 0, RSM overflow err 0
> RSM stat Q full err 0, no free buff Q err 0, RSM ignore rbd CPI count 0
> RSM ignore rbd CPI&PAD count 0, RSM ignore rbd abort count 0
> SEG stat Q full err 0, SEG underflow err 0
>
> Framer Chip Type PM7345
> Framer Chip ID 0x20
> Framer State RUNNING
> Defect Status NO ERRORS
> Loopback Mode NONE
> Clock Source INTERNAL (but the source of this clock is derived from
> LINE)
> DS3 Scrambling ON
> Framing DS3 C-bit w/PLCP framing
>
> TX cells 3244745
> TX bytes 171971485
> Last output time 01:50:40
> RX cells 1375370
> RX bytes 72944112
> Last input time 01:50:47
> Line Code Violations (LCV) 0
> DS3: F/M-bit errors 578375
> DS3: parity errors 15393959
> DS3: path parity errors 15363048
> DS3/E3: G.832 FEBE errors 72015
> T3/E3: excessive zeros 0
> PLCP BIP errors 53830051
> PLCP framing octet errors 1272044
> PLCP FEBE errors 3534
> uncorrectable HEC errors 4070158
> idle/unassigned cells dropped 0
> LCV errored secs 0
> DS3: F/M-bit errored secs 6628
> DS3: parity errored secs 6629
> DS3: path parity errored secs 6629
> T3/E3: excessive zeros errored secs 0
> DS3/E3: G.832 FEBE errored secs 6631
> PLCP BIP errored secs 6633
> PLCP framing octet errored secs 6633
> PLCP FEBE errored secs 2031
> uncorrectable HEC errored secs 6633
> LCV error-free secs 6633
> DS3: F/M-bit error-free secs 0
> DS3: parity error-free secs 0
> DS3: path parity error-free secs 0
> T3/E3: excessive zeros error-free secs 6633
> DS3/E3: G.832 FEBE error-free secs 1
> PLCP BIP error-free secs 0
> PLCP framing octet error-free secs 0
> PLCP FEBE error-free secs 4602
> uncorrectable HEC error-free secs 0
>
> PM 7345 registers (base 0x4A400000):
> cfgr 0x00, ier 0x08, isr 0x00,
> ctlr 0x00,
> imrr 0x21, dlcr 0x78, rboc_cier 0x00,
> rboc_isr 0x3F,
> t3frmr_cfgr 0x01, t3frmr_ier 0x03, t3frmr_isr 0x00,
> t3frmr_statr 0x20,
> rfdl_cfgr 0xFC, rfdl_esr 0xF8, rfdl_statr 0x87,
> rfdl_datar 0x87,
> pmon_pmr 0x97, pmon_iesr 0x93, pmon_lcvec0r 0x00,
> pmon_lcvec1r 0x00,
> pmon_fbeec0r 0x35, pmon_fbeec1r 0x34, pmon_sezdc0r 0x00,
> pmon_sezdc1r 0x00,
> pmon_peec0r 0xB4, pmon_peec1r 0x08, pmon_ppeec0r 0xB2,
> pmon_ppeec1r 0x88,
> pmon_febeec0r 0x08, pmon_febeec1r 0x00, t3tran_cfgr 0x07,
> t3tran_diagr 0x00,
> xfdl_cfgr 0x00, xfdl_isr 0x02, xfdl_txdatar 0x00,
> xboc_coder 0xFF,
> splr_cfgr 0x04, splr_ier 0x00, splr_isr 0x5F,
> splr_statr 0x08,
> splt_cfgr 0x0C, splt_ctlr 0x00, splt_diagr 0x00,
> splt_f1r 0x00,
> cppm_locmr 0xFC, cppm_copmr 0xFB, cppm_b1ec0r 0xBF,
> cppm_b1ec1r 0x1C,
> cppm_feec0r 0x70, cppm_feec1r 0x70, cppm_febec0r 0x00,
> cppm_febec1r 0x00,
> cppm_hcsec0r 0x47, cppm_hcsec1r 0x42, cppm_iucc0r 0xFF,
> cppm_iucc1r 0xFF,
> cppm_rcc0r 0x71, cppm_rcc1r 0x00, cppm_tcc0r 0xF2,
> cppm_tcc1r 0x00,
> rxcp_ctlr 0x2C, rxcp_frcr 0x00, rxcp_iesr 0x18,
> rxcp_iucph1r 0x00,
> rxcp_iucph2r 0x00, rxcp_iucph3r 0x00, rxcp_iucph4r 0x01,
> rxcp_iucmh1r 0xFF,
> rxcp_iucmh2r 0xFF, rxcp_iucmh3r 0xFF, rxcp_iucmh4r 0xFF,
> rxcp_upcph1r 0x00,
> rxcp_upcph2r 0x00, rxcp_upcph3r 0x00, rxcp_upcph4r 0x00,
> rxcp_upcmh1r 0xFF,
> rxcp_upcmh2r 0xFF, rxcp_upcmh3r 0xFF, rxcp_upcmh4r 0xFF,
> rxcp_hcscsr 0xFC,
> rxcp_lctctr 0xB4, txcp_ctlr 0xA4, txcp_iesr 0x18,
> txcp_iucph1r 0x00,
> txcp_iucph2r 0x00, txcp_iucph3r 0x00, txcp_iucph4r 0x01,
> txcp_iucph5r 0x52,
> txcp_iucpr 0x00, e3frmr_foptr 0x00, e3frmr_moptr 0x00,
> e3frmr_fier 0x00,
> e3frmr_fiisr 0x01, e3frmr_meier 0x00, e3frmr_meiir 0x00,
> e3frmr_mesr 0x00,
> e3tran_foptr 0x80, e3tran_sdoptr 0x83, e3tran_bip8emr 0x00,
> e3tran_maoptr 0x00,
> ttb_ctlr 0x04, ttb_ttisr 0x00, ttb_iar 0x00,
> ttb_idr 0x00,
> ttb_eptlr 0x00, ttb_ptlcsr 0x00, sffpcsr 0x31,
> pcr 0x30,
> v#
>
>
>
>
>
>
>
>
>
>
>
>
>
> Thanks!
> Yes, they said it was to the smart jack an "intrusive test" It was down
> completely for 30 minutes... I know that carriers can be difficult, but they
> are the ones who basically handle these MPLS routers for my company..
> (even though I have been responsible for the last 3 fixes on these
> routers...: ) Thanks to GS etc.....
>
> I appreciate the information and I am about to go and power cycle the
> router and reseat the card b/c I have nothing left to try at this point....
>
> Wish me luck..
>
>
> On 8/31/06, Sean C. <Upp_and_Upp@hotmail.com > wrote:
> >
> > Hi William,
> >
> > When you write the carrier claimed the 'circuit is clean', how did they
> > test? Was a LEC tech dispatched to the site, unplugged your cable from
> > the
> > dmarc, their equipment plugged into the dmarc, and they ran tests back
> > through their network? Yes, their test will take down your circuit, but
> > sometimes it's the only way to have the carrier prove their connection
> > (and
> > even that is suspect).
> >
> > The config/output looks normal (except for the glaring CRCs). Having a
> > smartnet replacement card issued shouldn't be that hard to request from
> > Cisco. Especially if you mention the carrier proved their network was
> > ok.
> >
> > Having worked as representing the customer to telco's for years though,
> > 80-90% of the issues are typically carrier related. So, unless the
> > carrier's performed the test above, (typically called a 'head-to-head
> > test'), I'd still be twisting the carrier's arm.
> >
> > Thinking outside the box, I live in the DC area. We haven't had any
> > major
> > T-storms come through here (yet), so I don't think something got zapped.
> >
> > Good luck and hope this helps (ATM can be a b*tch to prove to a carrier
> > sometimes),
> > Sean
> > ----- Original Message -----
> > From: "William Walla" <wwalla@gmail.com>
> > To: "Cisco certification" < ccielab@groupstudy.com>
> > Sent: Thursday, August 31, 2006 6:07 PM
> > Subject: OT ATM card issues
> >
> >
> > Hello guys (girls)
> >
> > I have been thinking that the telcos circuit was the ATM issue when now
> > the
> > telco has told me it is clean. IT is a DS3 and I started having issues
> > with
> > it just this morning. It is dropping about 8 - 10 % of the traffic on
> > the
> > ATM interface. Telco says the circuit is clean. The cable has been
> > checked
> > but not replaced (yet) don't have an available cable for it. I am
> > thinking
> > I might need to smartnet a new card for it. I have a lack of experience
> > with the ATM and if something seems obvious to you about the ROUTER
> > please
> > reply. No changes have been made to the confioguration in weeks btw.
> > I will be traveling out to the DC to physically take a look here in a
> > bit
> > and could use some advice if you have it!
> >
> > the interface looks like this:
> > ATM1/0 is up, line protocol is up
> > Hardware is RS8234 ATM DS3
> > MTU 4470 bytes, sub MTU 4470, BW 45000 Kbit, DLY 190 usec,
> > reliability 255/255, txload 1/255, rxload 1/255
> > Encapsulation ATM, loopback not set
> > Encapsulation(s): AAL5
> > 1023 maximum active VCs, 1 current VCCs
> > VC Auto Creation Disabled.
> > VC idle disconnect time: 300 seconds
> > Last input 00:00:00, output 00:00:00, output hang never
> > Last clearing of "show interface" counters 01:13:40
> > Input queue: 0/75/1/0 (size/max/drops/flushes); Total output drops: 5
> > Queueing strategy: Per VC Queueing
> > 5 minute input rate 27000 bits/sec, 17 packets/sec
> > 5 minute output rate 76000 bits/sec, 15 packets/sec
> > 108798 packets input, 15913207 bytes, 0 no buffer
> > Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
> > 0 input errors, 13846 CRC, 0 frame, 0 overrun, 0 ignored, 1 abort
> > 111079 packets output, 53483121 bytes, 0 underruns
> > 0 output errors, 0 collisions, 0 interface resets
> > 0 output buffer failures, 0 output buffers swapped out
> > ATM1/0.1 is up, line protocol is up
> > Hardware is RS8234 ATM DS3
> > Internet address is 70.247.49.38/30
> > MTU 4470 bytes, BW 45000 Kbit, DLY 190 usec,
> > reliability 255/255, txload 1/255, rxload 1/255
> > Encapsulation ATM
> > 108798 packets input, 15913207 bytes
> > 111077 packets output, 53481709 bytes
> > 884 OAM cells input, 904 OAM cells output
> > AAL5 CRC errors : 13845
> > AAL5 SAR Timeouts : 0
> > AAL5 Oversized SDUs : 0
> > AAL5 length violation : 3435
> > AAL5 CPI Error : 184
> > Last clearing of "show interface" counters never
> >
> > ---------
> > interface ATM1/0
> > no ip address
> > no ip route-cache cef
> > no ip route-cache
> > atm scrambling cell-payload
> > atm framing cbitplcp
> > no atm ilmi-keepalive
> > !
> > interface ATM1/0.1 point-to-point
> > ip address XX.XX.XX.XX. 255.255.255.252
> > ip authentication mode eigrp 1 md5
> > ip authentication key-chain eigrp 1 XXXXXX
> > no ip route-cache
> > pvc 15/65
> > protocol ip 70.247.49.37 broadcast
> > vbr-nrt 10000 9999 32
> > oam-pvc manage
> > encapsulation aal5mux ip
> >
> > Thanks!
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sun Oct 01 2006 - 16:55:39 ART