adding support for vJunos-switch

[akielaries]

This PR goes in hand with hellt/vrnetlab#138 for adding support for Juniper's vJunos-switch, a virtual instance of an EX2914. I added the below file I used to test as a lab-example

name: srlvjunos01

topology:
  nodes:
    n1:
      kind: srl
      image: ghcr.io/nokia/srlinux
      startup-config: srl.cli

    vswitch0:
      kind: vr-vjunosswitch
      image: vrnetlab/vr-vjunosswitch:23.2R1.14
      startup-config: vjunos.cfg

  links:
    - endpoints: ["n1:e1-1", "vswitch0:eth1"]
    - endpoints: ["n1:e1-2", "vswitch0:eth2"]
    - endpoints: ["n1:e1-3", "vswitch0:eth3"]
    - endpoints: ["n1:e1-4", "vswitch0:eth4"]
    - endpoints: ["n1:e1-5", "vswitch0:eth5"]
    - endpoints: ["n1:e1-6", "vswitch0:eth6"]

Apologies for the double PR

[hellt]

Hi @akielaries
can you add a doc entry? See https://github.com/srl-labs/containerlab/edit/main/docs/manual/kinds/vr-vmx.md

[hellt]

I used 23.1R1.8 image to try it out and something is not right when the login is attempted

2023-08-25 08:34:41,450: launch     INFO     VM started
'023-08-25 08:34:41,451: vrnetlab   DEBUG    writing to serial console: '
2023-08-25 08:34:41,451: vrnetlab   TRACE    waiting for 'login:' on serial console
2023-08-25 08:34:41,497: vrnetlab   TRACE    read from serial console: ' (vswitch0) (ttyu0)

login:'
2023-08-25 08:34:41,497: vrnetlab   DEBUG    writing to serial console: 'admin'
2023-08-25 08:34:41,497: vrnetlab   TRACE    waiting for 'Password:' on serial console
2023-08-25 08:34:42,417: vrnetlab   TRACE    read from serial console: ' 



FreeBSD/amd64 (vswitch0) (ttyu0)

login: 

FreeBSD/amd64 (vswitch0) (ttyu0)

login: admin
Password:'
2023-08-25 08:34:42,417: vrnetlab   DEBUG    writing to serial console: 'admin@123'
2023-08-25 08:34:42,417: vrnetlab   TRACE    waiting for 'vswitch0>' on serial console

It freezes waiting for a prompt to appear and maybe the prompt doesn't match or never appears

[akielaries]

Hello @hellt, I added some updates to the docs but I was unable to recreate this issue on my end with the script waiting for a CLI prompt in both 23.1R1.8 and latest 23.2R1.14. I tested this a few different times with both images.

2023-08-26 00:59:28,273: launch     INFO     VM started
'023-08-26 00:59:28,274: vrnetlab   DEBUG    writing to serial console: '
2023-08-26 00:59:28,274: vrnetlab   TRACE    waiting for 'login:' on serial console
2023-08-26 00:59:28,317: vrnetlab   TRACE    read from serial console: ' (vswitch0) (ttyu0)

login:'
2023-08-26 00:59:28,318: vrnetlab   DEBUG    writing to serial console: 'admin'
2023-08-26 00:59:28,318: vrnetlab   TRACE    waiting for 'Password:' on serial console
2023-08-26 00:59:28,560: vrnetlab   TRACE    read from serial console: ' 



FreeBSD/amd64 (vswitch0) (ttyu0)

login: 

FreeBSD/amd64 (vswitch0) (ttyu0)

login: admin
Password:'
2023-08-26 00:59:28,561: vrnetlab   DEBUG    writing to serial console: 'admin@123'
2023-08-26 00:59:28,561: vrnetlab   TRACE    waiting for 'vswitch0>' on serial console
2023-08-26 00:59:29,513: vrnetlab   TRACE    read from serial console: '

--- JUNOS 23.2R1.14 Kernel 64-bit  JNPR-12.1-20230613.7723847_buil
admin@vswitch0>'
'023-08-26 00:59:29,513: vrnetlab   DEBUG    writing to serial console: '
2023-08-26 00:59:29,513: launch     INFO     Login completed
2023-08-26 00:59:29,514: launch     TRACE    Startup config file /config/startup-config.cfg exists
2023-08-26 00:59:29,514: launch     TRACE    Parsed startup config file /config/startup-config.cfg
2023-08-26 00:59:29,514: launch     INFO     Writing lines from /config/startup-config.cfg
2023-08-26 00:59:29,515: vrnetlab   TRACE    waiting for '#' on serial console
2023-08-26 01:00:04,804: vrnetlab   TRACE    read from serial console: ' 

And then it goes on to configure the node based on the startup-config file passed in. Perhaps instead of the script waiting for the node name + ">" it can wait for just the prompt indicator ">".

[akielaries]

Ah okay I finally was able to replicate this on around the 5th try on the 23.1R1.8 image. Let me see how to fix this! The issue likely lies in vrnetlab, I will open a new PR for this fix in that repo. Interacting with the Junos CLI to configure is tricky since expected prompts can get lost in log messages on boot.

[hellt]

I got further with the skipped prompt watch you had done, but got stuck down the road again

Linux VMX-FPC0 4.8.28-WR9.0.0.20_standard #'
2023-08-27 17:15:08,317: vrnetlab   DEBUG    writing to serial console: 'cli'
2023-08-27 17:15:08,318: vrnetlab   TRACE    waiting for '>' on serial console
2023-08-27 17:15:32,396: vrnetlab   TRACE    read from serial console: '1 SMP PREEMPT Tue Jan 10 05:16:50 PST 2023 x86_64 x86_64 x86_64 GNU/Linux
cli[ 1153.728178] igb_uio: loading out-of-tree module taints kernel.
[ 1153.734242] igb_uio: Use MSIX interrupt by default

cat: /var/jnx/card/local/type: No such file or directory
cat: /etc/riot/init.conf: No such file or directory
Password:[ 1154.735547] igb_uio 0000:01:02.0: uio device registered with irq 1d
[ 1154.742062] igb_uio 0000:01:02.0: mapping 1K dma=0xaddf8000 host=ffff8800addf8000
[ 1154.749442] igb_uio 0000:01:02.0: unmapping 1K dma=0xaddf8000 host=ffff8800addf8000
[ 1154.786276] igb_uio 0000:01:03.0: uio device registered with irq 1e
[ 1154.792591] igb_uio 0000:01:03.0: mapping 1K dma=0xaddb4000 host=ffff8800addb4000
[ 1154.799813] igb_uio 0000:01:03.0: unmapping 1K dma=0xaddb4000 host=ffff8800addb4000
[ 1154.836834] igb_uio 0000:01:04.0: uio device registered with irq 1f
[ 1154.843088] igb_uio 0000:01:04.0: mapping 1K dma=0x4d31b000 host=ffff88004d31b000
[ 1154.850598] igb_uio 0000:01:04.0: unmapping 1K dma=0x4d31b000 host=ffff88004d31b000
OK
nested_env.sh sees AWS as no
nested_env.sh sees AWS as no
cat: /var/jnx/card/local/type: No such file or directory
0x0BAA
EAL: WARNING: cpu flags constant_tsc=yes nonstop_tsc=no ->'
2023-08-27 17:15:32,396: vrnetlab   DEBUG    writing to serial console: 'configure'
2023-08-27 17:15:32,396: vrnetlab   TRACE    waiting for '#' on serial console

Going to try the latest image

[akielaries]

Let me dig into this some more, my apologies! I am thinking the ideal way to get around interfering with the boot up messages is to wait for the FPC to come online to determine if our node is actually booted or not, this is the best indicator. See this:

admin@vswitch0> show chassis fpc    
                     Temp  CPU Utilization (%)   CPU Utilization (%)  Memory    Utilization (%)
Slot State            (C)  Total  Interrupt      1min   5min   15min  DRAM (MB) Heap     Buffer
  0  Present          Absent
  1  Empty           
  2  Empty           
  3  Empty           
  4  Empty           
  5  Empty           
  6  Empty           
  7  Empty           
  8  Empty           
  9  Empty           
 10  Empty           
 11  Empty           

admin@vswitch0> riot_fips_ossl_kats_handler: FIPS:Filled Results:FIPS Self-tests for TDES-CBC Encrypt:PASSED
FIPS Self-tests for TDES-CBC Decrypt:PASSED
FIPS Self-tests for AES-CBC Encrypt:PASSED
FIPS Self-tests for AES-CBC Decrypt:PASSED
FIPS Self-tests for AES-GCM Encrypt:PASSED
FIPS Self-tests for AES-GCM Decrypt:PASSED
FIPS Self-tests for SHA-1:PASSED
FIPS Self-tests for HMAC-SHA-1:PASSED
FIPS Self-tests for SHA-2-256:PASSED
FIPS Self-tests for HMAC-SHA-2-256:PASSED
FIPS Self-tests for RSA Encrypt/Decrypt:PASSED
FIPS Self-tests for RSA Sign/Verify:PASSED
 
admin@vswitch0> show chassis fpc    
                     Temp  CPU Utilization (%)   CPU Utilization (%)  Memory    Utilization (%)
Slot State            (C)  Total  Interrupt      1min   5min   15min  DRAM (MB) Heap     Buffer
  0  Online           Absent   0          0        0      0      0      0         0          0
  1  Empty           
  2  Empty           
  3  Empty           
  4  Empty           
  5  Empty           
  6  Empty           
  7  Empty           
  8  Empty           
  9  Empty           
 10  Empty           
 11  Empty           

The final messages we see just before the FPC does come online are the final messages related to boot (all related to encryption/hash verification) which ideally would signify our VM has completed bootup.

Within the launch.py script for vJunos-switch in https://github.com/hellt/vrnetlab/, I am thinking that once we login to the node we could do something similar to this:

        if match:  # got a match!
            if ridx == 0:  # login
                self.logger.info("VM started")

                # Login
                self.wait_write("\r", None)
                self.wait_write("admin", wait="login:")
                self.wait_write(self.password, wait="Password:")
                self.wait_write("\r", wait=None)
                self.logger.info("Login completed")

                # self.wait_write("show chassis fpc", "Online")
                # "show chassis fpc"
                    # if 'Onlining' or 'Present' in output
                        # FPC coming online, try again in a bit
                    # elif 'Online' in output
                        # FPC is online!, VM is booted, continue
               
                # run startup config
                self.startup_config()

Instead of continuing to runstartup_config we wait until the FPC comes online to determine if we should continue or not. When running show chassis fpc, the 3 possible states it could be in 'Present', 'Onlining', and 'Online'. I will dig into how I can do this with the wait_write method vrnetlab.py implements.

[hellt]

@akielaries I think that you maybe want to merge your startup-config to a file that you mount as a disk. That way you don't have to rely on wonky wait_write.

[akielaries]

@hellt This sounds great, I agree. Let me see if I can possibly append the existing juniper.conf file that I am attaching to the VM in the first place with some user configuration passed in from containerlab. This will get rid of the need for the startup_config() method and only rely on CLI interaction for logging in to confirm the node is booted.

[akielaries]

Hello, I mentioned in the hellt/vrnetlab#140 PR that I was able to get around the janky send/wait logic of the Junos CLI by appending the initial *.conf file that houses vrnetlab configs with the additional user config passed in from containerlab. I tested this on the latest 23.2R1.14 image and 23.1R1.8.

[hellt]

thanks @akielaries
I will test this later on

[codecov]

Codecov Report

Merging #1553 (cde03fd) into main (12f8fc5) will decrease coverage by 0.03%.
Report is 12 commits behind head on main.
The diff coverage is 3.63%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1553      +/-   ##
==========================================
- Coverage   48.62%   48.59%   -0.03%     
==========================================
  Files         132      133       +1     
  Lines       12688    12774      +86     
==========================================
+ Hits         6170     6208      +38     
- Misses       5818     5863      +45     
- Partials      700      703       +3     

Files Changed	Coverage Δ
cmd/generate.go	65.47% <ø> (ø)
nodes/vr_vjunosswitch/vr-vjunosswitch.go	1.85% <1.85%> (ø)
clab/register.go	100.00% <100.00%> (ø)

... and 10 files with indirect coverage changes