Go CCIE Go!! - A Cisco Certified Internetwork Expert

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” To: “Cisco certification” 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!