Hello.
For testing I use CHR in GNS3. CHR works fine in GNS3.
I try made LACP connection beetwin Fortigate/Dell and CHR, but LACP doesn’t up on Fortigate or Dell.
LACP works beetwin Fortigate and Dell.
After analyzed traffic was discoverd that CHR doen’t send LACP packages. CHR send only one package after disable bonding interface.
If use hardware Mikrotik the LACP ups fine. The problem only on CHR.
Is it feature or bug?
And how to show LACP status on CHR?
Same here, I’ve tried multiple things & parameters. I’m using CHR within GNS3. I’m using Wireshark to monitor traffic.
CHR is only sending one package once you disable the bonding interface, example:
It might be an issue with the configuration settings in your virtual host or the guest (GNS) but without more details it’s hard to say for sure. Also, monitoring virtual NICs with Wireshark sometimes needs specific settings in the virtual environment to work correctly.
Btw, you’re responding to a quite old thread and using an outdated version of ROS. Any particular reason you’re sticking with v6 instead of upgrading to ROS v7?
Even though this isn’t your exact setup, these might help you out:
I finally found the issue! When I create a new Mikrotik router in GNS3 (drag and drop), the network adapter type it get selected by default is Paravirtualized Network I/O (virtio-net-pci), and somehow it’s causing problems with LACP. To fix it, I just had to right click on the router, go to the Network tab, and select a new type such as Realtek 8138 Ethernet (rlt8139), and then it works! Why? I don’t know, perhaps the driver of the simulated network card for virtio-net-pci doesn’t support LACP very well.
So, Mikrotik CHR is actually working well and as expected, same configuration without any tricky parameter, it was just the network adapter type. (I don’t have permissions to edit this topic but we should marked as a solved so that others can leverage this info)
I’d still suggest upgrading to CHR ROS v7 since there’ve been major improvements in the new kernel’s network stack. For example it handles LACP better allowing for improved hardware resource utilization especially in dynamic environments with multiple link members and multi-core support.
I mean by default hypervisor host only expects VMs to connect to network using MAC-address given by host. But LACP may announce other MAC on links so host just blocks those eframes. Feature is called “Allow MAC Spoofing” or similar and is located in VM settings. Look into your hypervisor docs to find more information.
Yeah, and in some environments it’s enabled by default. @iocampomx; for future reference could you let us know what OS and virtual environment you’re running GNS on?