cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2234
Views
0
Helpful
25
Replies

Frame Relay not pinging

akafinal
Level 1
Level 1

Hi all, 

This is my first post, please be gentle. 

I have 3 routers (All ISR4321 routers) with these configs: 

 

---------------R1-----------------

int s0/1/0
ip add 10.1.1.1 255.255.255.252
en frame-relay
no frame-relay inverse-arp
frame-relay map ip 10.1.1.2 103 broadcast
frame-relay map ip 10.1.1.1 103
no shut

 

---------------R2-----------------
frame-relay switching
int s0/1/0
en frame-relay
frame-relay intf-type dce
frame-relay route 103 int s0/1/1 301
no shut

int s0/1/1
en frame-relay
frame-relay intf-type dce
frame-relay route 301 int s0/1/0 103
no shut

 

---------------R3-----------------

int s0/1/1
ip add 10.1.1.2 255.255.255.252
en frame-relay
no frame-relay inverse-arp
frame-relay map ip 10.1.1.1 301 broadcast
frame-relay map ip 10.1.1.2 301
no shut

 

I know it's a very simple set up but I'm still not able to ping from R1 to R3: 

R1#ping 10.1.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

 

I have gone through some troubleshooting myself with these commands: 

  show frame-relay pvc
  show frame-relay map
  show frame-relay route
  debug frame-relay lmi

 

Everything's up like in the docos (unless i'm missing something) but still not pinging. 

I've also attached the Cisco lab file here just in case. 

Any help will be much appreciated, 

Dan 

 

 

25 Replies 25

Hello

I agree your config does look correct - Can you post the output of those commands.
show frame-relay pvc
show frame-relay map
show frame-relay lmi

show interface serial x/x

One thing you could try is to default the serial interfaces and then shut them down, recreate FR on the interface which are still in a shutdown state, Disable inverse arp before you enable the interface again, then test.

 

The reason for this sometimes i have noticed on broadcast FR mappings if the interface is up before you disable inverse arp it can already have mapped a dlci.


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Hi Paul, 

Yes, shutting down before creating FR on the interface has been what I've been doing from the start. I've just given it another try but still same result. 

I have output results of most of the show commands and attached them to this reply. Seems like most results are displaying exactly what I'm supposed to see according to lab file (which is also attached in the original post) but tough luck :(. 

Hello

The LMI debug show that R2 is the DCE and the R1-3 are DTEs however R2 is only showing communication to one router ?
It could just be you have only captured the very first output but if you haven't then this shows a lack of communication from the FR switch towards one of your spokes

 

*Nov 8 12:23:41.997: Serial0/1/0(in): StEnq, myseq 78
*Nov 8 12:23:41.997: RT IE 1, length 1, type 0
*Nov 8 12:23:41.997: KA IE 3, length 2, yourseq 79, myseq 78
*Nov 8 12:23:41.997: Serial0/1/0(out): Status, myseq 79, yourseen 79, DCE up

 

From the same LMI debug i also see the rest msg type 0 from all 3 routers but again you could have captured this output just time the reset msg was sent ( every 60 seconds) however your timestamps from the 3 routers dont match again this could be due to not having any clock synchronization on the routers.

 

*Nov 8 11:31:14.806: Serial0/1/0(out): StEnq, myseq 85, yourseen 84, DTE up
*Nov 8 11:31:14.806: datagramstart = 0x7FB8F84F38AC, datagramsize = 13
*Nov 8 11:31:14.806: FR encap = 0xFCF10309
*Nov 8 11:31:14.806: 00 75 01 01 00 03 02 55 54
*Nov 8 11:31:14.807:
*Nov 8 11:31:14.808: Serial0/1/0(in): Status, myseq 85, pak size 21
*Nov 8 11:31:14.808: RT IE 1, length 1, type 0
*Nov 8 11:31:14.809: KA IE 3, length 2, yourseq 85, myseq 85
*Nov 8 11:31:14.809: PVC IE 0x7 , length 0x6 , dlci 103, status 0x2 , bw 0

 

So can you confirm from the FR switch (R2) you are indeed showing ingress/egress LMI requests from the 2 spokes rtrs and they include both (type1 & type 0) msg's


Also you could try removing the static FR mapping from the spokes and use dynamic mapping instead and test again.

 

Spoke rtrs
int x/x
shut
no frame-relay map ip x.x.x.x broadcast
no frame-relay map ip x.x.x.x
frame-relay inverse-arp
no shut


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Hi Paul,

 

I've updated the result of the LMI debug (but just on R2). I believe it does show ingress/ egress LMI requests from both spoke rtrs (see attached). On all 3 routers, there were both types of msg's (type 1 and type 0) as well. I took a screenshot and attached it to this post too. It's still not pinging. 

 

Also, I removed the static FR mapping from the spokes and use dynamic mapping instead just like instructed on the spoke Rtrs. On the hub router (R2), I've tried removing the mapping 'frame-relay route 103 int s0/1/1 301' on s0/1/0 and 'frame-relay route 301 int s0/1/0 103' on S0/1/1 and re-adding them on. But on both cases, ping still doesn't work. 

 

Dan

P.s. The clock sync on routers is not working as there are fresh routers and there's no NTP configured yet. I don't think this is preventing Frame Relay from working but please correct me if I'm wrong. 

Hello

Just to confirm you are pinging sourced from the serial interfaces?

access-list 100 permit ip host 10.1.1.x host 10.1.1.y
access-list 100 permit ip host 10.1.1.y host 10.1.1.x
debug ip packet detail 100
ping 10.1.1.x source serial x/x/x

show ver
show interfaces serial x/x


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Hi Paul, thanks heaps for all the useful commands. I've given all of them a try and made sure the ping sourced from the serial interface but still hitting the brick wall. I may have to discuss this with my supervisor to see if we need to get in touch with Cisco.

Hello

Quite interested into what serial adapters your using , can you post the following please.
sh run
sh version
sh controllers serial x.x.x


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Hello

As I have previously requested post the output from this please;
sh run
sh version
sh controllers serial x.x.x


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Hi Paul

 

Sorry did not see your request before. I've attached these files in this post

FYI, I've tried same commands on another three 2811 Routers (running IOS Version 15.1(4)M10, RELEASE SOFTWARE (fc2)), worked straight away.

Hello,

 

which IOS version are you running on your 4321 routers ? It could be that you are hitting the bug below:

 

ISR 4331 + NIM-1MFT-T1/E1 + Frame-relay circuit does not come up
CSCvc08339
Description
Symptom:
Same circuit works fine on 1841 router , issue is seen when the same circuit is connected on ISR4331 , controller flaps , PVC status in deleted state , tried changing the cable length configurations.

Conditions:
Issue is seen on ISR 4331 router , frame-relay circuits does not come up

Workaround:
No work around

 

Known Fixed Releases: (12)
Everest-16.5.1
Everest-16.4.2
Denali-16.3.3
Denali-11.3.3
16.5.1
16.5(0.122)
16.4.2
16.4(1.1)
16.3.3
16.3(1.85)

15.5(3)S5
11.3(3)

Thanks Georg for the reply, 

 

The version is 16.7.1 

"
Cisco IOS XE Software, Version 16.07.01
Cisco IOS Software [Fuji], ISR Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version 16.7.1, RELEASE SOFTWARE (fc6)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2017 by Cisco Systems, Inc."

 

So I believe the bug has been well fixed on this one as I did look up but saw no relevant bugs? 

Hello,

 

try and change the LMI type on the interfaces (this needs to be done on all interfaces). You have three options, try all three...

 

int s0/1/0
ip add 10.1.1.1 255.255.255.252
en frame-relay
no frame-relay inverse-arp

frame-relay lmi-type {ansi | cisco | q933a}
frame-relay map ip 10.1.1.2 103 broadcast
frame-relay map ip 10.1.1.1 103
no shut

 

 

Hey Georg,

Yes, tried all three types on all interfaces on all 3 Routers. Did not work. This is very odd.
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco