Log in to ask questions, share your expertise, or stay connected to content you value. Don’t have a login? Learn how to become a member.
HelloI have been testing vEX, vMX, and VQFX images with EVE-NG and GNS3, and so far, the only major issue I have run into is with link state. When connecting devices, disabling the interface on one side does not bring down the link on the other side. This makes it difficult to accurately test LAG.These have been bare metal deployments. I have not yet tested using the vJunos switch deployment guide on KVM in this forum to see if the scripts used have the same behavior.Is this a known issue? Link state works as expected with other vendor images.Thanks in advance
Hm that seems unusual, I'd have to check as it's been a little bit since I last used our EVE-NG instance, but I'm pretty sure it did link state with me. Are you using the community edition or the pro edition of EVE-NG? And which version of the vMX and such are you using? (also, nested image or separate VFP/VCP?)
This was the community edition of EVE-NG - 5.0.19. vEX 23.1R1.8 and 23.2R1.14vMX 22.2R1.9 nestedvMXVCP and vMXVFP 18.2R1.9 and 22.2R1.9vQFX RE and PFE 20.2R1.10I also followed the Juniper vJunos-switch - Deployment on KVM on this forum with the same results.Does the NIC have to support SR-IOV? I did find this is not supported with the onboard the 1Gb interfaces on the server I am using.
vJunos-switch, vJunosEvolved being lab only 'products' don't support SR-IOV - there is no intention of these lab VMs to be performant. They aren't supposed to be used for performant, service providing purposes (per the free licensing). If you had a older licensed version of VMX or have hacked VMX to be a VEX then yea, you can enable SR-IOV per the product docs, but these images aren't available past 23.2 due to product EOL.
Regarding the link state question, lemme go have a look - generally the virtual links don't have that sort of info available to them due to the way the links work (ie, bridged/tap'd to something else.
Thank youI should have phased that differently. I was wondering if SR-IOV support was a requirement for these images.This is for a lab environment that was intended to set ESI LAG. When testing with Cisco and Arista images, the link state was working as expected between connected devices which is why this discovery shocked me. I did try to manually disable the interface link by bringing down the bridge and interfaces on the host for the documented KVM example. The results were the same. The interfaces showing admin up with link down in the output below are those that did not have a network defined with virt-install on creation.
root@eve-ng:~# virsh net-info --network leaf1-spine1
root@eve-ng:~# brctl show virbr1
bridge name bridge id STP enabled interfaces
virbr1 8000.5254001ce88e no virbr1-nic
root@eve-ng:~# ip link set virbr1-nic down
root@eve-ng:~# ip link set virbr1 down
root@eve-ng:~# ip link set vnet0 down
root@eve-ng:~# ip link set vnet2 down
root@leaf1> show interfaces terse ge-0/0/*
Interface Admin Link Proto Local Remote
ge-0/0/0 up up
ge-0/0/0.16386 up up
ge-0/0/1 up up
ge-0/0/1.16386 up up
ge-0/0/2 up up
ge-0/0/2.16386 up up
ge-0/0/3 up down
ge-0/0/3.16386 up down
Thanks for the clarification - I'll have a look based on the examples you show here as to what might be going on.
Ok, so its not just a matter of twiddling the host interface/bridge down/up - the hypervisor needs to be aware of the change.
So using 'virsh' like this would down/up the interface:
root@r2> show interfaces ge* terse
ge-0/0/0.0 up up inet 184.108.40.206/24
root@q-jlab-01a:/var/home/abstine/vbx# virsh domiflist vjunos-sw1
Interface Type Source Model MAC
macvtap16 direct hmgmt0 virtio 52:54:00:d0:23:77
vnet487 bridge et0010 virtio 52:54:00:79:c4:e5
vnet488 bridge et0011 virtio 52:54:00:73:d4:c3
root@q-jlab-01a:/var/home/abstine/vbx# virsh domif-setlink vjunos-sw1 vnet487 down
Device updated successfully
root@r2> show interfaces ge* terse
ge-0/0/0 up down
ge-0/0/0.0 up down inet 220.127.116.11/24
But just doing "ip link set vnet487 down" doesn't do it as the hypervisor doesn't see the change and pass it along to the guest. Guessing eve-ng does the same thing by toggling the if state in the hypervisor
It also looks like the notification to the hypervisor for the source interface also does not take place when the interface is shut down on the guest. As long as it is known expected behavior, both sides of the interface can be disabled in the guest devices with close to synchronous commits, or script it up to bring both sides down with the KVM hypervisor. I'll have to look and see if there is a way to do this with EVE-NG and QEMU. Just started looking at this a couple of weeks ago, so I am very new to QEMU and KVM. This has been a good learning experience, and it seems I have not missed something in setup and configuration.Thank you!