In addition, in your configuration I don't see any dlci listed. What are they? You should have a frame-relay map statement or if using sub-interfaces you should use the interface-dlci command. To see the dlci do a show frame-relay pvc or show frame-relay map. It appears from the output of the show interface that you are not seeing the frame relay switch at all. (LMI DOWN)
Also I have seen bad cabling effect the telco's looping capabilities. Check your cables. Do you have a spare to swap it out. Did you provide the csu or the telco? Check your settings on the device, did you have a power outage, maybe something changed and needs to be changed back. If the telco provided the csu, escalate within the telco until they dispatch a CPE tech to assist and possibly replace the unit and/or cabling. If you provided the csu, as stated in a previous post, ask the telco to throw you loops from various COs (Central Offices) you want the first loop from the CO closest to you, then move out from there, taking steps at each CO. Has this ever worked? If not, I would request a Class A on the circuit immediately. A Class A is basically where the telco does a visual check at every place the circuit is punched down. Alot of times they find problems with the circuit there. Good Luck Debbie Westall --- reinhold fischer wrote: > it depends on the layer2 protocol and how the router > handles it if it sees > its own packets coming back. I am using loops often > to test a line if it > is ok or has any problem. I am not sure how > FrameRelay encapsulation > behaves when you loop the line but i think it sounds > feasible that it > will not come to an up/up state. To debug the > situation i would consider > that the framerelay link consist out of three parts: > > - the local loop on one side (first accessline to > the frame cloud) > - the framerelay cloud > - the local loop on the other side (second > accessline to the fr cloud) > > to test if the local loops are working fine i would > ask the carrier to > give you a loop on their side facing in your > direction so the signal > travels from your router to the providers framerelay > location, over the > loop and back to your router - without travelling > any framerelay related > equipment. You can set then a more 'loop-friendly' > encapsulation like > HDLC on your side and thoroughly test the line with > a few long pings to > see if any problems occur. If you have no problems > with that tests on > both of your lines to the frame-relay cloud, let the > provider remove the > loops and reconfigure your routers to frame relay. > You can assume then > that your local loops to the FR cloud are running > error-free. > > For more framerelay related debugging i can > recommend: > > http://www.cisco.com/warp/public/779/smbiz/service/troubleshooting/ts_fr.htm > > > hth > > Reinhold > > > On Wed, 12 Dec 2001, Telemachus Luu > wrote: > > > Hi, > > > > I am having some issues bringing up a 64k frame > relay circuit. Wcom seems > > to think it's a bad csu as they aren't able to > loop it. As a result, I did > > some testing on my end. I enabled inward bound > looping on the dsu also. > > For some reason, the line protocol for the serial > interface comes up for > > about 10 seconds, the comes back down. When I do > a shut and then a no > shut, > > again, it comes back up for about 10 seconds and > then goes back down. > > Here's the current config and a sh int ser... LMI > enq for send and receive > > still increment even when line protocol is in down > state... If I set the > > csu/dsu to loopback, shouldn't the line protocol > stay in up state forever? > > If so, what could be the issue here? > > > > interface Serial3/3 > > ip address 10.252.0.1 255.255.0.0 > > encapsulation frame-relay > > ! > > > > Serial3/3 is up, line protocol is down (looped) > > Hardware is M4T > > Internet address is 10.252.0.1/16 > > MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, > > reliability 255/255, txload 1/255, rxload > 1/255 > > Encapsulation FRAME-RELAY, crc 16, loopback not > set > > Keepalive set (10 sec) > > LMI enq sent 136, LMI stat recvd 0, LMI upd > recvd 0, DTE LMI down > > LMI enq recvd 146, LMI stat sent 0, LMI upd > sent 0 > > LMI DLCI 1023 LMI type is CISCO frame relay > DTE > > FR SVC disabled, LAPF state down > > Broadcast queue 0/64, broadcasts sent/dropped > 0/4, interface broadcasts 0 > > Last input 00:00:09, output 00:00:09, output > hang never > > Last clearing of "show interface" counters > 00:20:31 > > Input queue: 0/75/0/0 (size/max/drops/flushes); > Total output drops: 0 > > Queueing strategy: weighted fair > > Output queue: 0/1000/64/0 (size/max > total/threshold/drops) > > Conversations 0/1/256 (active/max active/max > total) > > Reserved Conversations 0/0 (allocated/max > allocated) > > 5 minute input rate 0 bits/sec, 0 packets/sec > > 5 minute output rate 0 bits/sec, 0 packets/sec > > 150 packets input, 2035 bytes, 0 no buffer > > Received 0 broadcasts, 0 runts, 0 giants, 0 > throttles > > 1 input errors, 0 CRC, 0 frame, 1 overrun, 0 > ignored, 0 abort > > 184 packets output, 2415 bytes, 0 underruns > > 0 output errors, 0 collisions, 22 interface > resets > > 0 output buffer failures, 0 output buffers > swapped out > > 36 carrier transitions DCD=up DSR=up > DTR=up RTS=up CTS=up > > > > Any help would be appreciated.. > > > > thanks [EMAIL PROTECTED] __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=29054&t=29002 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
