Labs

 View Only
last person joined: 21 hours ago 

Discover how to get the most of Juniper labs and share what you've built.
  • 1.  Link state with virtual devices

    Posted 11-10-2023 19:10

    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



    ------------------------------
    Chris Bauer
    ------------------------------


  • 2.  RE: Link state with virtual devices

     
    Posted 11-13-2023 04:46

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




  • 3.  RE: Link state with virtual devices

    Posted 11-13-2023 10:32

    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.




  • 4.  RE: Link state with virtual devices

    Posted 11-13-2023 12:55

    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.



    ------------------------------
    Art Stine
    ------------------------------



  • 5.  RE: Link state with virtual devices

    Posted 11-13-2023 13:38

    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

    ...



    ------------------------------
    Chris Bauer
    ------------------------------



  • 6.  RE: Link state with virtual devices

    Posted 11-13-2023 18:16

    Thanks for the clarification - I'll have a look based on the examples you show here as to what might be going on.

    Art



    ------------------------------
    Art Stine
    ------------------------------



  • 7.  RE: Link state with virtual devices

    Posted 11-14-2023 02:34

    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



    ------------------------------
    Art Stine
    ------------------------------



  • 8.  RE: Link state with virtual devices

    Posted 11-15-2023 17:30

    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!



    ------------------------------
    Chris Bauer
    ------------------------------