Cloud access through a switch not working

[bunub]

The above network architecture was deployed on a GNS3 VM with version 2.2.18 freshly installed in a ESXi Cluster (version 6.7.0). The Cloud1 and Cloud2 are connected to the eth2 interface of the VM that is linked to a VMWare network configured in promiscuous mode, as required.

When connecting a docker (or router) directly to the cloud, we can ping VMs inside the ESXi cluster. For example a ping from the ipterm2 to 10.10.10.95 works fine.

When connecting a docker to a GNS3 Ethernet switch and then to the cloud, it does not work. When measuring between the Switch1 and Cloud1, we can see the ARP request and reply, but when measuring between the ipterm1 and the Switch1, we see only the ARP request.

If we replace the Switch1 with a Cisco 3725 or IOUL2 switch, I got the same issue. When I do a "show mac-address-table" on the switch1 (when using Cisco switches), we see the MAC address of the ipterm1 on the wrong side (on e1 port).

And when doing a ping from ipterm1 to ipterm2, it works !

This issue concern ethernet frames that are not forwarded through the ethernet switch when they are coming from the "Cloud".

[ghost]

Promiscuous mode enabled on the vswitches?

——- Charles N Wyble Founder TSYS Group Email: charles@turnsys.com Phone: 818 280 7059 Matrix: @Charlesnw:turnsys.com

---

From: François Buntschu notifications@github.com Sent: Thursday, February 25, 2021 12:58:34 PM To: GNS3/gns3-server gns3-server@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: [GNS3/gns3-server] Cloud access through a switch not working (#1869)

[Screenshot 2021-02-25 at 19 49 27]https://user-images.githubusercontent.com/7402820/109201855-9ac5e580-77a2-11eb-8b6e-b08cc5b55724.png

The above network architecture was deployed on a GNS3 VM with version 2.2.18 freshly installed in a ESXi Cluster (version 6.7.0). The Cloud1 and Cloud2 are connected to the eth2 interface of the VM that is linked to a VMWare network configured in promiscuous mode, as required.

When connecting a docker (or router) directly to the cloud, we can ping VMs inside the ESXi cluster. For example a ping from the ipterm2 to 10.10.10.95 works fine.

When connecting a docker to a GNS3 Ethernet switch and then to the cloud, it does not work. When measuring between the Switch1 and Cloud1, we can see the ARP request and reply, but when measuring between the ipterm1 and the Switch1, we see only the ARP request.

If we replace the Switch1 with a Cisco 3725 or IOUL2 switch, I got the same issue. When I do a "show mac-address-table" on the switch1 (when using Cisco switches), we see the MAC address of the ipterm1 on the wrong side (on e1 port).

And when doing a ping from ipterm1 to ipterm2, it works !

This issue concern ethernet frames that are not forwarded through the ethernet switch when they are coming from the "Cloud".

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/GNS3/gns3-server/issues/1869, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAQSDGLTQMSK7DHBB4U3OLTTA2MVVANCNFSM4YHBTDWA.

[bunub]

Yes, as written. Otherwise the ping from ipterm2 to 10.10.10.95 will not work.

root@gns3-ipterm-2:~# ping 10.10.10.95
PING 10.10.10.95 (10.10.10.95) 56(84) bytes of data.
64 bytes from 10.10.10.95: icmp_seq=2 ttl=255 time=1.04 ms
64 bytes from 10.10.10.95: icmp_seq=3 ttl=255 time=0.764 ms

and from ipterm1:

root@gns3-ipterm-1:~# ping 10.10.10.95
PING 10.10.10.95 (10.10.10.95) 56(84) bytes of data.
From 10.10.10.100 icmp_seq=1 Destination Host Unreachable
From 10.10.10.100 icmp_seq=2 Destination Host Unreachable

[grossmj]

Not too sure why you get this problem. I know some users got some issues when directly using Ethernet interfaces via clouds.

Something worth trying is to use a Linux bridge instead. I would do something like this in the GNS3 VM:

sudo apt-get install bridge-utils
sudo brctl addbr mybridge
sudo brctl addif mybridge eth2
sudo ifconfig eth2 0.0.0.0
sudo ifconfig mybridge up
sudo ifconfig mybrige 10.10.10.95 netmask 255.255.255.0 up

Then use that bridge instead of eth2 in the cloud nodes

Please note that this won't survive a reboot of the VM.

[bunub]

I made the config you proposed. But I put 10.10.10.10/24 as address for the bridge, as 10.10.10.95 is assigned to a VM in the VMWare cluster.

gns3@gns3vm:~$ sudo brctl show mybridge
bridge name     bridge id               STP enabled             interfaces
mybridge                8000.0050569242a6       no              eth2
                                                                gns3tap0-4
                                                                gns3tap1-4
gns3@gns3vm:~$ 

gns3@gns3vm:~$ ifconfig mybridge
mybridge: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.10.10.10  netmask 255.255.255.0  broadcast 10.10.10.255
        inet6 fe80::250:56ff:fe92:42a6  prefixlen 64  scopeid 0x20<link>
        ether 00:50:56:92:42:a6  txqueuelen 1000  (Ethernet)
        RX packets 270  bytes 21822 (21.8 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 43  bytes 3426 (3.4 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

gns3@gns3vm:~$ 

I don't know what are the gns3tap added to this bridge. Added automatically by the gns3 server ??

Neither ipterm1 nor ipterm2 could ping the 10.10.10.95 virtual machine in the ESXi cluster through this bridge. Both terminal can ping the bridge address 10.10.10.10 and a ping between each ipterm works sometimes. Measuring trafic on the link between the ipterm2 and the cloud2 show only ARP request. Same for trafic between Switch1 and cloud1.

A ping from the GNS3 VM to my internal ESXi VM works:

gns3@gns3vm:~$ ping 10.10.10.95
PING 10.10.10.95 (10.10.10.95) 56(84) bytes of data.
64 bytes from 10.10.10.95: icmp_seq=1 ttl=255 time=0.709 ms
64 bytes from 10.10.10.95: icmp_seq=2 ttl=255 time=0.781 ms
^C
--- 10.10.10.95 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1015ms
rtt min/avg/max/mdev = 0.709/0.745/0.781/0.036 ms
gns3@gns3vm:~$ 

[bunub]

Here some additional troubleshooting steps: it seems that the gns3tap0-4 interfaces correspond to the "cable" connected from the Switch1 to Cloud1 and gns3tap1-4 is for the connection between ipterm2 and Cloud2. So when doing a tcpdump -i gns3tap0-4 -n on the GNS3 VM, I don't see the ARP reply going back (when doing a ping from ipterm1 to 10.10.10.95), I see only the request:

root@gns3vm:/var/log# tcpdump -i gns3tap0-4 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on gns3tap0-4, link-type EN10MB (Ethernet), capture size 262144 bytes
14:38:56.633712 ARP, Request who-has 10.10.10.95 tell 10.10.10.100, length 28
14:38:56.633888 ARP, Request who-has 10.10.10.95 tell 10.10.10.100, length 46
14:38:57.645247 ARP, Request who-has 10.10.10.95 tell 10.10.10.100, length 28
14:38:57.645658 ARP, Request who-has 10.10.10.95 tell 10.10.10.100, length 46
14:38:58.669169 ARP, Request who-has 10.10.10.95 tell 10.10.10.100, length 28

and when looking at the MAC forwarding table of mybridge:

root@gns3vm:/var/log# brctl showmacs mybridge
port no mac addr                is local?       ageing timer
  1     00:50:56:84:e5:0b       no                 0.16
  2     32:00:71:85:50:a4       yes                0.00
  1     a2:fb:f8:ad:d9:5e       no                 0.16
root@gns3vm:/var/log# 

Strange is that the ipterm1 is seen on port 1 (a2:fb:f8:ad:d9:5e) and the 10.10.10.95 VM also (00:50:56:84:e5:0b). 32:00:71:85:50:a4is the Mac address of the gns3tap0-4 interface.

When disabling the promiscuous mode on the VMWare switch, we have:

root@gns3vm:/var/log# brctl showmacs mybridge
port no mac addr                is local?       ageing timer
  1     00:50:56:84:e5:0b       no                31.00
  2     32:00:71:85:50:a4       yes                0.00
  2     a2:fb:f8:ad:d9:5e       no                 0.75
root@gns3vm:/var/log# 

That is correct ! But It's not forwarded further. The capture of trafic on the gns3tap0-4 is the same as above. We have exactly the same behaviour with ipterm2.

Any idea or other troubleshooting steps are welcome ;-)

[zacho112]

Not too sure why you get this problem. I know some users got some issues when directly using Ethernet interfaces via clouds.

Something worth trying is to use a Linux bridge instead. I would do something like this in the GNS3 VM:

sudo apt-get install bridge-utils
sudo brctl addbr mybridge
sudo brctl addif mybridge eth2
sudo ifconfig eth2 0.0.0.0
sudo ifconfig mybridge up
sudo ifconfig mybrige 10.10.10.95 netmask 255.255.255.0 up

Then use that bridge instead of eth2 in the cloud nodes

Please note that this won't survive a reboot of the VM.

Do you have more information about this issue with Ethernet interfaces and Clouds?

I'm using GNS to test some of our automated deployments and I've struggled for a couple of weeks trying to figure out why some tcp connections won't get connected between a Palo FW and the Panorama management server. I'm testing the same setup in multiple projects (one source project which gets duplicated, and we ZTP the devices in each project). One running project is working just fine, but if I have two (or more) running projects, there won't be a successful connection between the firewalls and the management system.

The firewalls are connected to a DHCP enabled vlan via the Cloud. And the managment server is reach over L3 in another (physical) environment. If I disconnect one of the firewalls from the Cloud the other will get connected and viseversa.

It's not duplicate MAC/IPs, and I've just tested with the bridge, which seems to work! I still need some more testing, but I would love to know more about the issue, and do some troubleshooting if that could help solve the real problem.

And btw. do you know a way to make this workaround survive a reboot?

[grossmj]

And btw. do you know a way to make this workaround survive a reboot?

On Ubuntu you will have to use netplan: https://www.tecmint.com/create-network-bridge-in-ubuntu/

[bunub]

Hi, After a new try with a fresh 2.2.20 install, I have the same issues with directly connected ethernet Interfaces via clouds.

Also made a try with a bridge with a permanent config, here is the content of the /etc/netplan/90_gns3vm_static_netcfg.yaml:

# This file describes the network interfaces available on your system
# For more information, see netplan(5).

# Uncomment the following lines if you want to manually configure your network

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: yes
#      addresses:
#        - 10.10.10.2/24
#      gateway4: 10.10.10.1
#      nameservers:
#          addresses: [8.8.8.8, 8.8.4.4]

  bridges:
    my bridge:
      dhcp4: no
      addresses:
        - 10.10.10.10/24
      interfaces:
        - eth2

The bridge config is now persistant after a reboot, but it does not solve the original issue. I have exactly the same behaviour I described in my previous message

Any other ideas or test to do to solve this ?

[zacho112]

I don't know why, but the bridge-workaround stopped working after a short while, and I wasn't able to get it working again. Resolving in moving away from using GNS for now :(

[bunub]

Just try right now with the 2.2.21 release (fresh install again). With or without the bridge-workaround, still the same issue.

[bunub]

Has this issue been resolved in 2.2.22 ?

[grossmj]

Has this issue been resolved in 2.2.22 ?

Unfortunately no, I think it could be fixed in version >= 3.0 that we are working on. We plan to drop uBridge and directly use Linux bridges.

[bunub]

This issue is has been assigned to the 3.1 milestone, when will this new version of GNS-3 be released ?

[grossmj]

This issue is has been assigned to the 3.1 milestone, when will this new version of GNS-3 be released ?

Unfortunately, we have to release version 3.0 first, version 3.1 could take months to be released.

[athompson-merlin]

Another workaround appears to be to: use a GNS3 Hub instead of a GNS3 Switch. Not sure yet if this solves everything 100%, but initial results are promising.