search

GNS3 / gns3-gui

GNS3 Graphical Network Simulator
http://www.gns3.com
GNU General Public License v3.0
2.15k stars 434 forks source link

Neighborship flapping with latest version of IOU #2884

Closed ralikhani110 closed 1 year ago

ralikhani110 commented 4 years ago

Using IOUL3 15.7(3) on latest version of GNS3. When I configure EIGRP or OSPF between to routers, although the neghiborship creates as normal, but it is flaps with the following messages continuously:

R7# Oct 31 15:27:38.531: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.0.1 on Ethernet0/0 from LOADING to FULL, Loading Done R7# Oct 31 15:28:33.705: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.0.1 on Ethernet0/0 from FULL to DOWN, Neighbor Down: Dead timer expired Oct 31 15:28:33.709: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.0.1 on Ethernet0/0 from LOADING to FULL, Loading Done R7# Oct 31 15:29:38.246: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.0.1 on Ethernet0/0 from LOADING to FULL, Loading Done R7# Oct 31 15:30:33.737: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.0.1 on Ethernet0/0 from FULL to DOWN, Neighbor Down: Dead timer expired Oct 31 15:30:33.765: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.0.1 on Ethernet0/0 from LOADING to FULL, Loading Done R7# Oct 31 15:31:38.507: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.0.1 on Ethernet0/0 from LOADING to FULL, Loading Done R7# Oct 31 15:32:33.870: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.0.1 on Ethernet0/0 from FULL to DOWN, Neighbor Down: Dead timer expired *Oct 31 15:32:33.877: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.0.1 on Ethernet0/0 from LOADING to FULL, Loading Done R7#

grossmj commented 4 years ago

I am not sure we can do something about it. Do you face the same issue with other IOU versions?

ralikhani110 commented 4 years ago

Yes. Same problem with version 15.5. I do not have the same problem in EVE-ng.

TheLordOfTheKings commented 4 years ago

Which version of GNS3 and OS do you use? Please share your project and let us test it.

ralikhani110 commented 4 years ago

2.2 and 2.2.1 of GNS3. I have not tested this situation in previous versions, so far. Two versions of IOU i have used for this purpose: 15.5 and 15.7 for L3. Also, i use GNS on Windows 10 1803, fully updated. I use Microsoft's native antivirus.

TheLordOfTheKings commented 4 years ago

I'm using GNS3 v2.1.21 on Win10 and using latest L3 IOU 15.7(3).M2, there are no problems regarding neighbor-ship adjacency or exchange states. On another Win7 VM i have GNS3 v2.2.0 and using Dynamips c7200 15.2-4 there are no problems!

Can you confirm your GNS3 VM is updated to 2.2.1 and KVM is enabled? On server summary section inside GNS3 gui, does your VM have low CPU and RAM usage?

ralikhani110 commented 4 years ago

I use several Cisco images like CSR1000v and IOSv. I have this problem on only IOUL3 images. Yes, I confirm I am using GNS3 v2.2.1 and also confirm that there are no resource bottleneck when this problem occurs.

TheLordOfTheKings commented 4 years ago

Then may i suggest to rollback to a more stable and tested GNS3 v2.1.21 until 2.2 branch gets fully stable and patched up?

grossmj commented 4 years ago

@ralikhani110 what is the filename of your IOU image?

ralikhani110 commented 4 years ago

i86bi_LinuxL3-AdvEnterpriseK9-M2_157_3_May_2018.bin i86bi-Linux-L3-AdvEnterprisek9-Ms.155-2.T.bin

grossmj commented 4 years ago

Do you use the GNS3 VM?

grossmj commented 4 years ago

I tested L3 IOU 15.7(3).M2 OSPF config between 2 routers and I could find anything wrong. Has you system/GNS3 VM enough CPU/RAM?

ralikhani110 commented 4 years ago

Thanks for your reply;

I tested the situation again and find that when I enable IGP routing protocols on DMVPN infrastructure, the problem appears. But without this infrastructure, as you said, everything is OK!

As I said before, EVE-ng does not have this problem even in this (DMVPN) infrastructure.

grossmj commented 4 years ago

@ralikhani110 interesting finding. Can you post a picture of your topology with configs so we can reproduce the issue?

Thanks

ralikhani110 commented 4 years ago

This is the topology:

image

R1 config: R11#show run interface tunnel 0 Building configuration...

Current configuration : 305 bytes ! interface Tunnel0 ip address 10.0.0.11 255.255.255.0 no ip redirects ip nhrp map multicast 192.168.1.13 ip nhrp map 10.0.0.13 192.168.1.13 ip nhrp network-id 1 ip nhrp nhs 10.0.0.13 ip ospf network point-to-multipoint ip ospf 1 area 0 tunnel source Ethernet0/0 tunnel mode gre multipoint end

R11#sh run | s r o router ospf 1 R11#

R2 config: R12#sh run interface tunnel 0 Building configuration...

Current configuration : 287 bytes ! interface Tunnel0 ip address 10.0.0.12 255.255.255.0 no ip redirects ip nhrp map 10.0.0.13 192.168.1.13 ip nhrp network-id 1 ip nhrp nhs 10.0.0.13 ip nhrp redirect ip ospf network point-to-multipoint ip ospf 1 area 0 tunnel source Ethernet0/0 tunnel mode gre multipoint end

R12#sh run | s r o router ospf 1 R12#

R3 config: R13#show run interface tunnel 0 Building configuration...

Current configuration : 228 bytes ! interface Tunnel0 ip address 10.0.0.13 255.255.255.0 no ip redirects ip nhrp network-id 1 ip nhrp redirect ip ospf network point-to-multipoint ip ospf 1 area 0 tunnel source Ethernet0/0 tunnel mode gre multipoint end

R13#sh run | s r o router ospf 1 R13#

grossmj commented 4 years ago

Have you tried to replace the switch by an IOU L2 node?

ralikhani110 commented 4 years ago

Yes. I used with the same problem. I am using EVE right now for testing this situation and everything works like a charm on it.

grossmj commented 4 years ago

Is the switch in the middle an IOU node or a simple switch?

ralikhani110 commented 4 years ago

I tested both scenarios.

ralikhani110 commented 4 years ago

If you wish, I can give you UltraView remote access to you, If you want to dig the problem more.

grossmj commented 4 years ago

Thanks, I will test this on my side. What if you increase the OSPF dead timer? maybe this could be a workaround in the meantime...

ralikhani110 commented 4 years ago

I did so. But nothing has changed. The interesting part of this problem is that, in the above scenario, only R2 has this problem and R1 behaves as normal.

TheLordOfTheKings commented 4 years ago

For dmvpn phase3 shouldn't you use "ip nhrp redirect" only on hub and "ip nhrp shortcut" on spokes? On R2 you have "ip nhrp redirect". Can you "no" it and use "ip nhrp shortcut" on your both spokes?

ralikhani110 commented 4 years ago

Based on cisco docs, it has not any bad effect for using these two commands on both hub and spoke routers.

TheLordOfTheKings commented 4 years ago

Others having the same issue: https://gns3.com/community/discussion/iosvl2-to-router-ospf-flapping

TheLordOfTheKings commented 4 years ago

I have double checked this issue on GNS3 v2.1.21 and it doesn't seem to be affected. everything looks normal. It seems to be only an issue on GNS3 2.2.x branch. I wish it could be addressed and prioritized within v2.2 milestone.

grossmj commented 4 years ago

I will compare the 2 branches to see if I find something. This is strange because I think we haven't touched anything on the IOU part between the two version. Anyway, I will investigate.

cristian-ciobanu commented 4 years ago

I think the problem is not strictly related to IOU since on the GNS3 forum users mentioned that the neighborship was flapping also between IOSvL2 (Qemu) and CSRv1000v.

grossmj commented 4 years ago

I think the problem is not strictly related to IOU since on the GNS3 forum users mentioned that the neighborship was flapping also between IOSvL2 (Qemu) and CSRv1000v.

In this case I may suspect something is wrong with uBridge.

cristian-ciobanu commented 4 years ago

I just did some tests by setting up OSPF neighbors between 2 IOU images and another between and IOSvL2 and CSR1000v and did not experienced any flapping issue for the last 3 days since when the topology is running. 

IOU1#show ip ospf neighbor detail | i up
    Neighbor is up for 3d10h
IOU2#show ip ospf neighbor detail | i up
    Neighbor is up for 3d10h
IOSvL2#show ip ospf neighbor detail | i up
    Neighbor is up for 3d10h
CSR1000v#show ip ospf neighbor detail | i up
    Neighbor is up for 3d10h

image

My GNS3 setup is local GNS3 gui and server is running on the same Linux machine and I'm running the latest version 2.2.10. I remember I have encountered this flapping issue between IOSvL2 and CSR1000v when the GNS3 server is remote a while ago (client on Windows, server remote on Ubuntu 18.04 machine).

EVE-NG setup is on the same machine and I assume this happens only when the server is remote and not local. If someone having the OSPF flapping issues can share their project I can run it on my local instance to check if I experience the same problem.

Toine517 commented 3 years ago

I think I'am experiencing OSPF adjacencies flapping.

I'am running gns3 v2.1.15 and gns v2.2.15 on the same machine (same windows, same vmware workstation pro), with same IOU file in a simple minimal topology (just ospf and L3 interfaces are configured)

with GNS3 version 2.1.15 / vmware workstation 15 pro 15.5.6 build-16341506, ospf work just as expected : "sh ip ospf neighbor" displays a dead-time between 30 and 40 secondes. wireshark display hello packets every 10 seconds.

with GNS3 version 2.2.15 / vmware workstation 15 pro 15.5.6 build-16341506, ospf shows periodic "from FULL to DOWN, Neighbor Down: Dead timer expired" and "from LOADING to FULL, Loading Done". wireshark display hello packet every 60 seconds. "sh ip ospf neighbor" displays inconsistant values, with a dead-time of 8 minutes. "sh ip ospf neighbor detail" displays unrealistic values such as "Neighbor is up for 584942417y18w".

The topolofgy is given below : 4 routers in square R1,R2,R3 and R4

R1:e0/0 --------------------- e0/0:R2 R1:e0/3 --------------------- e0/3:R4 R3:e0/0 --------------------- e0/0:R4 R3:e0/3 --------------------- e0/3:R2

The configuration are given below :

[R1] hostname R1 int e0/0 ip add 192.168.12.1 255.255.255.0 no shut int e0/3 ip add 192.168.14.1 255.255.255.0 no shut router ospf 1 router-id 1.1.1.1 network 0.0.0.0 255.255.255.255 area 0 end

[R2] hostname R2 int e0/0 ip add 192.168.12.2 255.255.255.0 no shut int e0/3 ip add 192.168.23.2 255.255.255.0 no shut router ospf 1 router-id 2.2.2.2 network 0.0.0.0 255.255.255.255 area 0 end

[R3] hostname R3 int e0/0 ip add 192.168.34.3 255.255.255.0 no shut int e0/3 ip add 192.168.23.3 255.255.255.0 no shut router ospf 1 router-id 3.3.3.3 network 0.0.0.0 255.255.255.255 area 0 end

[R4] hostname R4 int e0/0 ip add 192.168.34.4 255.255.255.0 no shut int e0/3 ip add 192.168.14.4 255.255.255.0 no shut router ospf 1 router-id 4.4.4.4 network 0.0.0.0 255.255.255.255 area 0 end

ralikhani110 commented 3 years ago

I have this issue on the latest version of IOSv over EVE-ng, too.

TheLordOfTheKings commented 3 years ago

Do you use VMware Workstation to run GNS3VM? If not, you should. Another solution could be using older GNS3 v2.1.21 and the corresponding GNS3VM. In general, this version works flawlessly. I believe GNS3 devs should higher up the priority of fixing this issue along with fixing the problems regarding other server-related issues.

grossmj commented 3 years ago

One thing worth trying would be to take the uBridge executable from v2.1.21 (the one in the GNS3 VM, should be in /usr/local/bin/ubridge) and put it in the latest GNS3 VM. Don't forget to add the network capabilities back with setcap cap_net_admin,cap_net_raw=ep /usr/local/bin/ubridge This would allow us to isolate the issue which I suspect is in uBridge. Thanks :+1: