vSRX: Issues with Junos startup config load

[vista-]

Currently, loading a Junos startup config in conf format fails on the vSRX due overly eager matching on '#' characters, and also due to no delays being used while inserting the startup configuration.

One case where the # character might be erroneously matched is ## SECRET-DATA being present in the supplied startup configuration:

2024-06-14 09:12:31,871: vrnetlab   DEBUG    writing to serial console: '    host-name vsrx1;
}
...
            mode main;
            proposals mgmt-vpn-demo01-ike-prop;
            pre-shared-key ascii-text "$9$aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"; ## SECRET-DATA
...
2024-06-14 09:12:31,872: vrnetlab   DEBUG    writing to serial console: ''
2024-06-14 09:12:31,872: vrnetlab   DEBUG    writing to serial console: ''
'024-06-14 09:12:31,872: vrnetlab   DEBUG    writing to serial console: '
'024-06-14 09:12:31,872: vrnetlab   DEBUG    writing to serial console: '
2024-06-14 09:12:31,873: vrnetlab   TRACE    waiting for '#' on serial console
2024-06-14 09:12:31,955: vrnetlab   TRACE    read from serial console: '
...
            mode main;
            proposals mgmt-vpn-demo01-ike-prop;
            pre-shared-key ascii-text "$9$aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"; #'
2024-06-14 09:12:31,955: vrnetlab   DEBUG    writing to serial console: 'commit'
2024-06-14 09:12:31,955: vrnetlab   TRACE    waiting for '#' on serial console
2024-06-14 09:12:31,955: vrnetlab   TRACE    read from serial console: '#'
2024-06-14 09:12:31,955: vrnetlab   DEBUG    writing to serial console: 'exit'
2024-06-14 09:12:31,956: vrnetlab   TRACE    waiting for '>' on serial console

This is easy to fix by inserting an additional match for load complete, which gets displayed once the inserted configuration is parsed up.

@@ -132,12 +133,19 @@ class VSRX_vm(vrnetlab.VM):
                     self.wait_write("load merge terminal", "#")
                     #read the contents of the startup config from the beginning and dump it to the terminal
                     self.wait_write(first_line, "[Type ^D at a new line to end input]")
                     self.wait_write(file.read(), None)
                     #send CTL-D and CTL-R x2.
                     self.wait_write('\x04', None)
                     self.wait_write('\x04', None)
                     self.wait_write('\x0d', None)
                     self.wait_write('\x0d', None)
+                    self.wait_write("\x0A", "load complete")

Due to no delays/waiting being implemented, and due to no feedback from Junos when a large amount of configuration is pasted, it is hard to tell when it is safe to send Ctrl+D during the configuration load procedure. If it is sent too early, and the current line is not an empty newline, it is ignored.

To work around this, it is possible to introduce a delay for inserting the configuration. Inserting the configuration line by line also helps us to manage this issue:

@@ -132,12 +133,19 @@ class VSRX_vm(vrnetlab.VM):
                     self.wait_write("load merge terminal", "#")
                     #read the contents of the startup config from the beginning and dump it to the terminal
                     self.wait_write(first_line, "[Type ^D at a new line to end input]")
-                    self.wait_write(file.read(), None)
-                    #send CTL-D and CTL-R x2.
-                    self.wait_write('\x04', None)
-                    self.wait_write('\x04', None)
-                    self.wait_write('\x0d', None)
-                    self.wait_write('\x0d', None)
+                    config_lines = file.readlines()
+                    config_lines = [line.rstrip() for line in config_lines]
+                    # baud rate on vSRX is 38400, 10 bits per byte with 8N1 serial settings
+                    #% stty
+                    #  speed 38400 baud;
+                    sleep_per_byte = 1.0 / (38400.0 / (1.0+8.0+1.0))
+                    fudge_factor = 1.1  # 10% more sleep than we need, just to give ourselves a comfortable margin
+                    for line in config_lines:
+                        self.wait_write(line, None)
+                        time.sleep((len(line)) * sleep_per_byte * fudge_factor)
+                    self.wait_write("\x0A", None)
+                    self.wait_write("\x04", None)
+                    self.wait_write("\x0A", "load complete")

An alternative fix for both issues would be to adopt the startup configuration loading method used in the vJunos VM types, where an ISO containing the startup config is mounted, from where Junos automatically loads its configuration. This is supported by vSRX and vSRX 3.0: https://www.juniper.net/documentation/us/en/software/vsrx/vsrx-consolidated-deployment-guide/vsrx-kvm/topics/task/security-vsrx-kvm-bootstrap-config.html

This alternate approach would also help standardise the method of initially configuring Junos-based VMs, but in exchange, support for set-based configurations would likely have to be dropped.

Any feedback on which approach would fit better would be appreciated!

[vista-]

Fixed by #209