Re: OT ATM card issues

From: Sean C. (Upp_and_Upp@hotmail.com)
Date: Fri Sep 01 2006 - 01:42:45 ART


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!



This archive was generated by hypermail 2.1.4 : Fri Sep 01 2006 - 15:41:59 ART