04-17-2019 07:18 PM
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
04-17-2019 10:27 PM - edited 04-17-2019 10:38 PM
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.
04-19-2019 05:21 PM - edited 04-22-2019 08:32 PM
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 :(.
04-20-2019 03:49 AM - edited 04-20-2019 03:51 AM
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
04-22-2019 08:42 PM - edited 04-22-2019 10:04 PM
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.
04-23-2019 01:36 AM - edited 04-23-2019 01:40 AM
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
04-23-2019 05:05 PM
04-24-2019 12:44 AM - edited 04-24-2019 12:45 AM
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
04-24-2019 04:53 AM - edited 04-24-2019 04:53 AM
Hello
As I have previously requested post the output from this please;
sh run
sh version
sh controllers serial x.x.x
04-24-2019 04:50 PM
04-23-2019 06:02 PM - edited 04-23-2019 08:41 PM
FYI, I've tried same commands on another three 2811 Routers (running IOS Version 15.1(4)M10, RELEASE SOFTWARE (fc2)), worked straight away.
04-18-2019 01:21 AM
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)
04-19-2019 05:23 PM
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?
04-20-2019 01:01 AM
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
04-22-2019 08:45 PM
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