@michaely wrote:
Thanks and you used only one image or two?
Since from what I read vmx 15.1 needs 2 VMs to run properlyDid you use any license/trial or something? or just the one that comes with it?
↧
Playing with Juniper vMX on VIRL
↧
Playing with Juniper vMX on VIRL
@june03 wrote:
vMX comes with two, one is for the control plane the other is for data plane. Do not import the PFE. Use the other one. Also, em2 is equivalent to the ge-0/0/0, so connect that to other routers/switches/servers and u should be all set.
↧
↧
Playing with Juniper vMX on VIRL
@michaely wrote:
Thanks.
So we are using only the control plane VM, right?
I think that once you'll have PFE too you will see ge- interfaces.Will test that
↧
Playing with Juniper vMX on VIRL
@june03 wrote:
this image jinstall64-vmx-14.1R5.4-domestic.img import into Virl.
in order to get the PFE to work, u have to combine both images, then we will see the ge-0/0/0. i yet to figure that part out.
↧
Playing with Juniper vMX on VIRL
@CurtisJTroabugh wrote:
Has anyone found a way to do configuration extraction yet? I have been able to inject configuration into both vSRX and vMX but have not been able to extract the configuration. This makes configuration management a nightmare right now.
↧
↧
Playing with Juniper vMX on VIRL
@skynw wrote:
Hi Curtis,
can you describe how to inject the config?
Im currently not able even to connect the vMX router to anything else.
Cheers
Marcel
↧
Playing with Juniper vMX on VIRL
@CurtisJTroabugh wrote:
EDIT
Sorry, I was being dumb. I forgot that the vSRX is essentially a security device and not a router.
![:grin:]( ":grin:")
After making a proper security configuration I was able to get things working again.=====================================================================================
So, not sure what happened but my vSRX nodes are broken. They wont pass data at all. I put a ridiculously slimmed down config into both two vSRX nodes and tried to ping between them and get nothing. Anyone know what might have caused this?
system { host-name vSRX2; root-authentication { encrypted-password "$1$md82yXyu$jINve2XDKMVrWhy.hMzrQ0"; ## SECRET-DATA } } interfaces { ge-0/0/2 { unit 0 { family inet { address 192.168.0.2/24; } } } } system { host-name vSRX; root-authentication { encrypted-password "$1$md82yXyu$jINve2XDKMVrWhy.hMzrQ0"; ## SECRET-DATA } } interfaces { ge-0/0/4 { unit 0 { family inet { address 192.168.0.1/24; } } } }
@Marcel,
Were you able to boot the vMX routers with VM Maestro? When you try to connect what happens?
↧
Playing with Juniper vMX on VIRL
@Jade_Deane wrote:
Has anyone made progress towards extracting and restoring configurations?
↧
Playing with Juniper vMX on VIRL
@vaibhav_agrawal wrote:
Hi, I created the subtype exactly as you mentioned, I then created a image using jinstall64-vmx-15.1F4.15-domestic.vmdk” file and got the following error while starting the simulation, "VIRL node with requested ID; junipervmx-1 already exists"
I then copied and created an image with jinstall-vmx-14.1R1.10-domestic.img and now I am getting a slight different error "There are images required by topology, but not available to STD: "Juniper vMX"Any pointers on what I am missing in either case will be of great help
thanks
↧
↧
Playing with Juniper vMX on VIRL
@Bastien_Pilat wrote:
I got the OpenStack installation scripts from Juniper, the easiest way I found to have a running image is to simply add it via Glance :
glance image-create --file=<image filename> --name=<glance image name> --property hw_vif_model=e1000 --property hw_disk_bus=ide --disk-format=qcow2 --container-format=bare --is-public FalseIt gets added and working properly this way.
I force the image statically when building the topology, in the node properties
↧
Playing with Juniper vMX on VIRL
@Bastien_Pilat wrote:
Hi Fred,
Unfortunately using this method, mpls forwarding doesn't seem to work. Sig is OK, but labels cannot be applied on trafic for interfaces emX without a proper MIC running.
I'm trying to get the vm_local_rpio="1" thing running, I've no PANIC messages, but the MIC is in perpetual "testing" mode and like you, disappears randomly (I'd say, once the RE has had enough of testing the MIC without it going up properly). I'm gonna ping my local Juniper reps to see if this is still a valid method with the latest vMX images.
Otherwise, we may have to boot both vcp & vpfe for having a functionnal forwarding plane.
↧
Playing with Juniper vMX on VIRL
@Bastien_Pilat wrote:
Working on it, super ugly (I'm no programmer so the code is fugly
) but somewhat functionnal.
Since JunOS use .gz configuration files on the router, I can't see any way to have it added from outside unfortunately, so I relied on manual scripts on the host.Basically, steps I've used :
- Make an image (snapshot for example) with a predefined admin user named "virl" and its corresponding ssh key configured (key being your virl user on the VIRL server). If you use any other user to connect to the VIRL host, configure this user instead. Also, this image should have ssh service enabled.
- have a kind of post-start script that you manually launch after the simulation is up that :
1) use the VIRL REST API to get the vMX console port & Management address. You basically gets everything you need from this nice API.
2) connect through console port to configure the management IP on em0 interface so that the router gets reachable from management
3) fetch the config for the host, push it via scp, then issue a "configure;load set 'filename';commit" command through ssh on the routerYou could probably setup your image for netconf and use netconf for pushing configurations, but I used minimal packages on my CML server and everything was already there for ssh, not netconf.
- The config extracting script does the opposite, simply issue a "show configuration | display set | no-more" command via ssh and save the result on file on the host.
↧
Playing with Juniper vMX on VIRL
@vaibhav_agrawal wrote:
Hi Bastiemn, thanks a lot for the suggestion, a couple of questions the image file can either be .img or .vmdk and how to associate the subtype to the image
↧
↧
Playing with Juniper vMX on VIRL
@Bastien_Pilat wrote:
It's probably dependant on the hypervisor used to run VIRL, we are running a baremetal VIRL over a Ubuntu server w/ kvm, and it only supports qcow2 image types.
So a .vmdk would have to be converted in our case :qemu-img convert -O qcow2 <VMDK image file>.vmdk <target image file>.imgThe resulting .img file should now be usable in VIRL.
If you're running VIRL over another hypervisor, I don't know which format are supported and how to do the conversion if needed.As for Subtype/Image association, it's probably done in the subtype parameters, there :
"baseline_image": ""
in the parameters Fred gave. He didn't associate, I think if you put there the name of the image you have defined with glance (--name parameter), it should do the trick automatically. You'll probably also want to define a flavor to be associated with the"baseline_flavor": ""
parameter.
Again, it can be done with OpenStack, with nova this time. The Juniper OpenStack installation scripts does this:nova flavor-create vmx-vcp auto 4096 20 1
This adds the flavor in VIRL as well.
With"baseline_flavor": "vmx-vcp"
in your subtype definition, this should associate it with the flavor
↧
Playing with Juniper vMX on VIRL
@vaibhav_agrawal wrote:
Thanks a ton, i have a baremetal installation and after using a .img file I am able to boot the same.
↧
Playing with Juniper vMX on VIRL
@Jade_Deane wrote:
If anyone could figure out how to combine images and make this work it would be @flex. @flex you ever looked into vMX?
↧
Playing with Juniper vMX on VIRL
@drodrig wrote:
Hi guys,
I’m going to describe my experience trying to get the vMX working on VIRL
I don’t know why, but simply “uploading” the jinstall64-vmx-15.1F4.15-domestic.img did not work for me.
I got a bunch of:
swapper pid 1 tid 100007 ran for 25210 ms
panic: Root mount failed, startup aborted.
KDB: stack backtrace:
kdb_backtrace(c0d028ca,c0d9db20,c0c9301c,f8846c90,c6eeb000) at kdb_backtrace+0x29
panic(c0c9301c,20) at panic+0x21e
vfs_mountroot(c0d9d860,0,c0c8b5c4,229,0) at vfs_mountroot+0x15f
start_init(0,f8846d38,c0c8c38c,367,0) at start_init+0x40
fork_exit(c0598ac2,0,f8846d38) at fork_exit+0x84
fork_trampoline() at fork_trampoline+0x8
--- trap 0, eip = 0, esp = 0xf8846d70, ebp = 0 ---Entering boot mastership relinquish phase
KDB: enter: panic
[thread pid 1 tid 100007 ]
Stopped at kdb_enter+0x106: movl $0xc0d039f0,0(%esp)
db>and:
PCB Group initialized for udppcbgroup
PCB Group initialized for tcppcbgroup
Kernel thread "wkupdaemon" (pid 46) exited prematurely.
Trying to mount root from ufs:/dev/ad0s1aManual root filesystem specification:
: Mount using filesystem
eg. ufs:/dev/da0a
? List valid disk boot devices
Abort manual inputmountroot>
What worked for me was getting 14.1R1:
And converted the image:
qemu-img convert -f vdi -O qcow2 vMX.vdi vMX.qcow2
Fire Up the vMX.qcow2 image directly with KVM
kvm -M pc-1.0 -enable-kvm -m 2048 -smp 2,sockets=2,cores=1,threads=1 -hda ./vMX.qcow2 -net nic,model=e1000,macaddr=00:01:00:ff:88:01 -nographic
Edited the fstab to get the proper devices that VIRL uses (and not the ad0s1a used normally)
The final fstab:
version 3
Device Mountpoint FStype Options Dump Pass
/dev/vtbd0s1a / ufs rw 1 1
proc /proc procfs rw 0 0/dev/vtbd0s1b none swap sw 0 0
/dev/vtbd0s1e /config ufs rw 2 2
/dev/vtbd0s1f /var ufs rw 2 2
/dev/vtbd1s1 /config msdosfs rw 0 0halt the instance, and now upload the resulting vMX.qcow2 using the subsystem that people have described, into VIRL
{
"dynamic-subtypes": [
{
"interface_management": "em0",
"baseline_image": "",
"plugin_base": "vSRX",
"baseline_flavor": "",
"plugin_name": "vMX",
"cli_protocol": "telnet",
"plugin_desc": "Juniper vMX router",
"gui_visible": true,
"interface_pattern": "em{0}",
"interface_range": 10,
"hw_ram": 3072,
"cli_serial": 3,
"deprecated_use": ""
}
]
}On the VMMaestro you’ll able to put this into your topology, and make sure that you give some initial configuration, like initial root authentication.
I don’t know if this is the easiest procedure, but the happy world that people describe on the post with simply uploading the image was not like that for me
↧
↧
Playing with Juniper vMX on VIRL
@flex wrote:
@Jade_Deane thanks for the kind words
Actually, I never used vMX. From what I read here in the forum, its also not only about merging two images, since they have two separate functions (control and data plane). I'm a little bit short on time right now, but maybe, I'll also have a try
Actually, I never used vMX. From what I read here in the forum, its also not only about merging two images, since they have two separate functions (control and data plane). I'm a little bit short on time right now, but maybe, I'll also have a try ↧
Playing with Juniper vMX on VIRL
@hritter wrote:
Hi Marcel,
The procedure for the vMX is almost the same as for the vSRX. The only thing that changes is the entry for the config disk in /etc/fstab, which is as follow:
/dev/vtbd0s1 /config msdosfs rw 0 0
Hope this helps,
Harold
↧
Playing with Juniper vMX on VIRL
@fcuiller wrote:
Hi all,
Here is my experience installing Juniper vMX 14.1R5.4 in my VIRL.
This vMX version normally uses several VMs: one for the vCP (jinstall64-vmx-14.1R5.4-domestic.img) and one for the vPFE (vPFE-20150707.img or vPFE-lite-20150707.img). Both VM communicate via the em1 internal interface. This architecture is by design to allow packet forwarding at high throughput. However this 2 VM architecture is a challenge for us to install in a VIRL, there are 2 solutions:
build a nested VM (Ubuntu 14.04 containing both vCP and vPFE, then import this VM into VIRL)
use only the vCP VM, and try to use it for our simulation. I will describe this solution below.
With this reference: https://ivorde.com/juniper-vmx-virtual-mx-router-in-vmware-esxi-5-5/ I found a trick to avoid installing the vPFE and enable a local virtual PFE. (edit /boot/loader.conf and add vm_local_rpio="1". save and reload)
This should allow to use a vPIC and associated ge-0/0/x interfaces. However, I never managed to have a stable vMX platforrm (several traceback such i386_junos[2946]: fpc0 PANIC PANIC PANIC PANIC PANIC PANIC and i386_junos[2946]: fpc0 Watchdog fired). I also never managed to get connectivty with the ge-0/0/x interfaces, the virtual PIC disapears randomly.
I gave up and use the solution mentioned here: don't enable the local vPFE and use instead em interfaces. I share below the subtype I created:
{
"dynamic-subtypes": [
{
"plugin_name": "Juniper vMX",
"hw_disk_bus": "ide",
"plugin_base": "generic",
"interface_first": 1,
"interface_pattern": "em{0}",
"hw_vcpus": 4,
"baseline_flavor": "",
"plugin_desc": "Juniper vMX",
"gui_visible": true,
"config_file": "/config/juniper.conf.gz",
"gui_icon": "router",
"hw_ram": 3072,
"interface_management": "em0",
"config_disk_type": "cdrom",
"cli_serial": 3,
"hw_vm_extra": "",
"interface_range": 10,
"baseline_image": ""
}
]
}Then I added the jinstall64-vmx-14.1R5.4-domestic.img VM image.
For this particular vMX version, it's important not to use em1 interface as data: remember em1 is used for internal communication (it's by default allocated a 172.16.0.1/16). The first usable interface is em2. Either plug em1 to something and don't use it, or set em1 as dummy interface.
With this setup, I managed to get IP connectivity between my em2 (and following) interfaces and configure OSPF and LDP.
Thanks
Fred
↧