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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=29041&t=29002 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
