10-08-2010 06:15 AM - edited 03-04-2019 10:02 AM
I have an 1841 router configured for frame-relay. The frame-relay is up but I am unable to ping the interface. can anyone help
Solved! Go to Solution.
10-08-2010 09:34 AM
Your local router is putting the frame on the wire or alteast its trying to,
Do you have access to the far end ?
Again FYI..
When the local router sends a echo-request, the router on the other end has to put back the frame back on to its local dlci and sent back the echo-request to the local router.
Then again the local router seeing the echo request would reply with a echo-reply which goes again to the far end.
And when this echo-reply comes back to the local router one ping is completed...and yeah it works like that..-:)
R1#pi 10.1.1.1 rep 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 44/44/44 ms
R1#
*Mar 1 02:51:14.947: Serial1/0.1(o): dlci 102(0x1861), pkt type 0x800(IP), datagramsize 104
*Mar 1 02:51:14.959: Serial1/0(i): dlci 102(0x1861), NLPID 0x3CC(IP), datagramsize 104 <<<<<<<<<<<<<
*Mar 1 02:51:14.967: Serial1/0.1(o): dlci 102(0x1861), pkt type 0x800(IP), datagramsize 104
*Mar 1 02:51:14.983: Serial1/0(i): dlci 102(0x1861), NLPID 0x3CC(IP), datagramsize 104
10-08-2010 06:54 AM
Frame relay is a multiaccess network but it doesnt support broadcast.
So for frame relay multipoint to work we need to explicitly add the layer 2 address of all the L3 destinations which needs to be reached with the exception of the point-to-point type.
So you need to map your IP address to the local dlci and it will do the trick
say:- fram map ip
and if i remember there should be atleast one broadcast keyword at the end of the dlci
10-08-2010 06:57 AM
The connection is Pont to Point any other thoughts
10-08-2010 07:14 AM
Please be very clear in the question.
Put some relevant snippets and your observation..
10-08-2010 07:29 AM
I have turned on debug ip icmp and get no output when i ping the interface all other interfaces are ok. I have tried an extended ping but the result is the same.
The frame link would seem to be up ok
Main Interface
Serial0/0/0 is up, line protocol is up
Hardware is GT96K Serial
MTU 1500 bytes, BW 192 Kbit/sec, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation FRAME-RELAY IETF, loopback not set
Keepalive set (10 sec)
CRC checking enabled
LMI enq sent 1052, LMI stat recvd 1052, LMI upd recvd 0, DTE LMI up
LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
LMI DLCI 0 LMI type is ANSI Annex D frame relay DTE segmentation inactive
Broadcast queue 0/64, broadcasts sent/dropped 180/0, interface broadcasts 0
Last input 00:00:09, output 00:00:04, output hang never
Last clearing of "show interface" counters 02:55:29
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 0 bits/sec, 0 packets/sec
1147 packets input, 21849 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
2075 packets output, 126228 bytes, 0 underruns
0 output errors, 0 collisions, 3 interface resets
0 unknown protocol drops
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up
Sub Interface
Serial0/0/0.16 is up, line protocol is up
Hardware is GT96K Serial
Description: wan-Frame Relay PVC 16
Internet address is xxxxxxxxx/30
MTU 1500 bytes, BW 192 Kbit/sec, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation FRAME-RELAY IETF
CRC checking enabled
Last clearing of "show interface" counters never
10-08-2010 08:12 AM
sh frame pvc 16
do a ping and check the output and input packets.
can you do a detailed debug if the router is not in production ?
deb fram packet
ping x.x.x.x rep 1 ?
do you observer i/o ?
10-08-2010 08:31 AM
Thanks for you help with this
I tried a ping and the input packets do not increase but the output packets do
does that suggest a problem at the far end?
10-08-2010 08:38 AM
Anytime !
Yes, even though its a point to point interface the packet/frame has to reach the other end router and bounce back.
It is more likely to be the far end issue !
10-08-2010 08:42 AM
Hi to back up the fact that the issue is at the far end this is the output from the frame debug which is showing the packets traversing the interface. What do you think?
133287: Oct 8 15:37:12.827 UTC: Serial0/0/0.16(o): dlci 16(0x401), NLPID 0x3CC(IP), datagramsize 104.
133288: Oct 8 15:37:14.827 UTC: Serial0/0/0.16(o): dlci 16(0x401), NLPID 0x3CC(IP), datagramsize 104.
133289: Oct 8 15:37:16.827 UTC: Serial0/0/0.16(o): dlci 16(0x401), NLPID 0x3CC(IP), datagramsize 104.
133290: Oct 8 15:37:18.827 UTC: Serial0/0/0.16(o): dlci 16(0x401), NLPID 0x3CC(IP), datagramsize 104.
133291: Oct 8 15:37:20.826 UTC: Serial0/0/0.16(o): dlci 16(0x401), NLPID 0x3CC(IP), datagramsize 104.
10-08-2010 09:34 AM
Your local router is putting the frame on the wire or alteast its trying to,
Do you have access to the far end ?
Again FYI..
When the local router sends a echo-request, the router on the other end has to put back the frame back on to its local dlci and sent back the echo-request to the local router.
Then again the local router seeing the echo request would reply with a echo-reply which goes again to the far end.
And when this echo-reply comes back to the local router one ping is completed...and yeah it works like that..-:)
R1#pi 10.1.1.1 rep 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 44/44/44 ms
R1#
*Mar 1 02:51:14.947: Serial1/0.1(o): dlci 102(0x1861), pkt type 0x800(IP), datagramsize 104
*Mar 1 02:51:14.959: Serial1/0(i): dlci 102(0x1861), NLPID 0x3CC(IP), datagramsize 104 <<<<<<<<<<<<<
*Mar 1 02:51:14.967: Serial1/0.1(o): dlci 102(0x1861), pkt type 0x800(IP), datagramsize 104
*Mar 1 02:51:14.983: Serial1/0(i): dlci 102(0x1861), NLPID 0x3CC(IP), datagramsize 104
10-08-2010 09:43 AM
Thank you for all you help the the problem has now been resolved. I had an incorrect ip add on my end of the link.
10-08-2010 10:43 AM
oops....
So next time lets be sure and start from below the Layer 1.
I call that TCP/IP or OSI Layer 0 (human error) !
Thanks for pts !
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide