Labs

Hello

I 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?)

Hello

I 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

This was the community edition of EVE-NG - 5.0.19. 

vEX  23.1R1.8 and 23.2R1.14
vMX 22.2R1.9 nested
vMXVCP and vMXVFP 18.2R1.9 and 22.2R1.9
vQFX RE and PFE 20.2R1.10

I 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.

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?)

Hello

I 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

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.

This was the community edition of EVE-NG - 5.0.19. 

vEX  23.1R1.8 and 23.2R1.14
vMX 22.2R1.9 nested
vMXVCP and vMXVFP 18.2R1.9 and 22.2R1.9
vQFX RE and PFE 20.2R1.10

I 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.

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?)

Hello

I 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

Thank you

I 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

Name:           leaf1-spine1

UUID:           3080d1fa-b66a-4542-b695-2cf3742d7eaa

Active:         yes

Persistent:     yes

Autostart:      yes

Bridge:         virbr1

root@eve-ng:~# brctl show virbr1

bridge name bridge id STP enabled interfaces

virbr1 8000.5254001ce88e no virbr1-nic

vnet0

vnet2

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

...

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.

This was the community edition of EVE-NG - 5.0.19. 

vEX  23.1R1.8 and 23.2R1.14
vMX 22.2R1.9 nested
vMXVCP and vMXVFP 18.2R1.9 and 22.2R1.9
vQFX RE and PFE 20.2R1.10

I 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.

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?)

Hello

I 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

Thank you

I 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

Name:           leaf1-spine1

UUID:           3080d1fa-b66a-4542-b695-2cf3742d7eaa

Active:         yes

Persistent:     yes

Autostart:      yes

Bridge:         virbr1

root@eve-ng:~# brctl show virbr1

bridge name bridge id STP enabled interfaces

virbr1 8000.5254001ce88e no virbr1-nic

vnet0

vnet2

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

...

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.

This was the community edition of EVE-NG - 5.0.19. 

vEX  23.1R1.8 and 23.2R1.14
vMX 22.2R1.9 nested
vMXVCP and vMXVFP 18.2R1.9 and 22.2R1.9
vQFX RE and PFE 20.2R1.10

I 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.

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?)

Hello

I 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

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 

Interface               Admin Link Proto    Local                 Remote

ge-0/0/0                up    up

ge-0/0/0.0              up    up   inet     2.1.1.4/24      

                                   multiservice

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    

Interface               Admin Link Proto    Local                 Remote

ge-0/0/0                up    down

ge-0/0/0.0              up    down inet     2.1.1.4/24      

                                   multiservice

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

Thank you

I 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

Name:           leaf1-spine1

UUID:           3080d1fa-b66a-4542-b695-2cf3742d7eaa

Active:         yes

Persistent:     yes

Autostart:      yes

Bridge:         virbr1

root@eve-ng:~# brctl show virbr1

bridge name bridge id STP enabled interfaces

virbr1 8000.5254001ce88e no virbr1-nic

vnet0

vnet2

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

...

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.

This was the community edition of EVE-NG - 5.0.19. 

vEX  23.1R1.8 and 23.2R1.14
vMX 22.2R1.9 nested
vMXVCP and vMXVFP 18.2R1.9 and 22.2R1.9
vQFX RE and PFE 20.2R1.10

I 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.

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?)

Hello

I 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