I have eve-ng running fine with 2 x vMX currently (CP and FP) and have installed a vSRX (as I need to test some VPN/NAT configurations).
When I power on the vSRX I get to the following point:
JUNOS procfs is initialized.Timecounters tick every 1.000 mseccan't re-use a leaf (pvidb_rootnode)!Registering tcp_platform_dependent = tcp_handle_special_portsmd0: Preloaded image </packages/sets/active/boot/os-kernel/contents.izo> 8897024 bytes at 0xffffffff824e41c0SMP: AP CPU #1 Launched!Kernel thread "wkupdaemon" (pid 43) exited prematurely.Trying to mount root from cd9660:/dev/md0.uzip ...mode = 0100644, inum = 6910, fs = /.mountpanic: ffs_valloc: dup alloccpuid = 0Uptime: 21sAutomatic reboot in 15 seconds - press a key on the console to abort--> Press a key on the console to reboot,--> or switch off the system now.
All this allows me to do is reboot the vSRX.
This is continuous and I cannot get the vSRX to actually go to the CLI. It just keeps getting to this point and power cycling.
I only have access to the qcow2 image and have configured that as per the eve-ng vSRX documentation.
Maybe there is a dependency too.... The html portal shows the vSRX as being available though...
Any ideas as to why this is happening please?
Add on to the above information:
I downloaded the qcow2 image from Juniper and it is the same size as the file I already have.
Again, I followed the procedure shown on the Juniper site:
Copy file to directory created. (Used SCP)
Rename file to "virtioa.qcow2"
I am using eve-ng Community on VMWorkstation 12.
I am still having the same problem where the vSRX is just constantly power cycling. As I have mentioned above, I have no problem at all with the vMX.
what vSRX Version are you trying to spin up?
Are you using the default Template from EVE-NG or did you change Settings (especially RAM or CPU)?
Have you tried other vSRX Versions to see if this behavior is also affecting other images?
I am using the version that is also available on the Juniper vMX and vSRX sebsite.
The VM is in VMware Workstation 12 and is being run on a Tower system (plenty of power). I changed the CPU is 8 and the memory is 16gb. I am running the VM in bridged mode as the IP Address will remain the same. This is for external connectivity and that works fine.
I had been informed that a "Serial Port" was required for the VM that the vSRX is running on so I have added that too and it has made no difference at all.
As i said, the vMX is running perfectly and I have no issues with that. Just the vSRX.
I cannot try a different version as I have no other version qcow2 image.
Have you already tried to "wipe" the vSRX after you changed the CPU and RAM?
Power it off, right-click it and select "wipe" - after that power it up again.
Serial is not needed on the Host as far as I know (at least I don't have one and everything works fine).
Are you running the latest EVE-NG?
So, I have got a little further. Purchased a new machine, re-installed VMware Workstation 12 Pro.... Re-installed the eve-ng.ova and created the VM. Gave the VM 16GB RAM and 8 CPUs. Bridged interface as easier and also statically assigned the MAC on the router to ensure same address always applied.
Re-installed vMX and re-installed vSRX
Opened the portal and created a new lab. Created vMX-Control-Plane and Forwarding-Plane and they work fine. No issues, as per before.
This time when I created the vSRX in the lab, I gave it 4 x CPU and 8192 RAM. So, I got to a logon prompt this time.... But now I get to the following point when I try and enter the CLI:
--- JUNOS 19.2R1.8 Kernel 64-bit XEN JNPR-11.0-20190517.f0321c3_builroot@:~ # cli<xnm:error xmlns="http://xml.juniper.net/xnm/1.1/xnm" xmlns:xnm="http://xml.juniper.net/xnm/1.1/xnm"><message>could not open render database schema: /var/run/db/render.db.qxiFkKrD</message></xnm:error>could not initialize the rendererroot@:~ # ~veriexec: no fingerprint for file='/root' fsid=85 fileid=118272 gen=147665435 uid=0 pid=93961/root: Authentication error.root@:~ #root@:~ # confconf: Command not found.root@:~ # cli<xnm:error xmlns="http://xml.juniper.net/xnm/1.1/xnm" xmlns:xnm="http://xml.juniper.net/xnm/1.1/xnm"><message>could not open render database schema: /var/run/db/render.db.fbDCrLmn</message></xnm:error>could not initialize the renderer
So, a little further but stuck still....
I think there's something wrong with the image itself.
I also had a similar error once and this was due to a bad file.
Let me try to get someone from JNPR to send you a known working file 🙂
Thank you for the help. I have now installed vSRX-NG and it works perfectly so I think you are correct.
I do have a quick question for you as an add on please (it is quick)...
Does the vSRX require a license to enable PPPoE (MLPPP at the server end)? I have configured correctly but yet only sends out a PADI with no response, but I have noticed the following in the license output:
root# run show pppoe versionPoint-to-Point Protocol Over Ethernet, Version 1. rfc2516Maximum sessions = 1024PADI resend timeout = 2 secondsPADR resend timeout = 16 secondsMaximum resend timeout = 64 secondsMaximum configured AC timeout = 2 seconds
I think there should be a line that says "pppoe = enabled" ... but there is not, and also the license information:
root> show system licenseLicense usage:Licenses Licenses Licenses ExpiryFeature name used installed neededlogical-system 0 3 0 permanentVirtual Appliance 1 1 0 59 daysremote-access-ipsec-vpn-client 0 2 0 permanent
Licenses installed:License identifier: E420588955License version: 4Software Serial Number: 20150625Customer ID: vSRX-JuniperEvalFeatures:Virtual Appliance - Virtual Appliancecount-down, Original validity: 60 days
Actually, it appears that it is working but I am getting the following as a response:
IO send ... PADI for pp0.0Jan 13 20:49:46 Discovery Input: PADO packet received on uifl (idx 72)Jan 13 20:49:46 Malformed packet: no ac name field in incoming PADO packetJan 13 20:49:49 IO send ... Packet resend for pp0.0Jan 13 20:49:49 Discovery Input: PADO packet received on uifl (idx 72)Jan 13 20:49:49 Malformed packet: no ac name field in incoming PADO packetJan 13 20:49:54 IO send ... Packet resend for pp0.0
usually, you have a 60day License for everything.
So in theory (if you are doing the PPPoE over ge- instead of reth) PPPoE should work.
PPPoE over redundant Ethernet interface
Note: Starting in Junos OS Release 15.1X49-D100 and Junos OS Release 17.4R1, vSRX supports Point-to-Point Protocol over a redundant Ethernet interface (PPPoE).
However I don't know PPPoE very well - so you might start a new Topic for this issue 🙂
Glad, that your vSRX is working now.