Jean-Christophe Manciot
Jean-Christophe Manciot
In another topology, with 2 ASAv connected to 2 CSR 1000v, no such issue.   Either there is something special with the IOS-XRv, or the cloud-ASAv connection...
Yes, the latter is correct: The issue is still there with only the following 2 nodes:  
@grossmj You're saying that in the last topology, ubridge must be running. The issue for me is that **it uses way too much CPU power**. Sitting & waiting for some...
If I connect the ASAv to a tap interface on the cloud instead, the issue is gone. No ping travel on the connection. FYI, the ubridge process does not run...
No, the **traffic in excess is directly produced by ubridge somehow**: **Traffic on lo without GNS3 running**: **15kbits/s**  **Traffic on lo with GNS3 running and a...
Some more information about my setup: qemu 2.8.1(Debian 1:2.8+dfsg-6) libpcap 1.8.1-3
@grossmj The traffic you show has nothing to do with this issue which is about endless unsolicited ICMP Ping packets looping and generating way too much traffic and consuming way...
I confirm that on the CSR-1000v-16.11.1b with 32 interfaces set: - there is no actual GigabitEthernet0 despite having Gi0 displayed in the GUI (in second position) - only 26 interfaces...
It seems to be a misinterpretation of the field "Firs port name" on my part. I've just found a way to make the interfaces labels start at 1: ``` First...
@grossmj This issue has evolved with GNS3 GUI/Server 2.2.29: - CSR 1kv 16.11.1b interfaces start with Gi0 on the GUI but start with GigabitEthernet1 on the device CLI on an...