VIRL on Packet Cloud—Some thoughts
For the last couple of days I’ve been messing with Cisco’s VIRL on Packet’s bare metal service. I don’t do enough labbing now to spend multiple thousands of dollars building a lab in my house, and I want something that I can use from anywhere without opening a lot of holes in my home network when I’m on the road, so the Packet service seems like something useful to get running.
Forthwith, some observations and hints for those who might be thinking about doing this. Some of this might be obvious to other folks, I know, but—maybe me writing them down here will be somehow helpful, and save other folks some time.
An observation—this all feels a little (okay, maybe a lot) clunky’ish. There’s a lot of steps, it takes a long time to set up, etc. There are a lot of moving parts, and they interconnect in interesting ways. Maybe this will all get better over time, but for now, if you’re going to do this, plan on spending at least a half a day, probably more, just getting all the pieces to work.
Some places I ran into trouble, and things I needed to configure that I had to play with to discover.
If you have problems with connection timeouts from vagrant into the virtual box, make certain virtualization is turned on in your bios. Any time you change virtualization, etc., it’s best to destroy the virtualbox machine and let the vagrant script rebuild it. It took me two or three such rebuilds to get past the initial steps of getting ssh’d into the virtualbox machine.
You have to copy client.ovpn to your configurations directory in openvpn each time you run through the startup process, as the ip addresses change each time. I tried to use the Windows 10 native vpn client, but I can’t figure out how to transfer the information in the config file into the native client’s settings—this would be just one bit cleaner if I could figure that out. If I do, I’ll post something on it later. Beyond this, I tried to get openvpn to read the config file from the vagrant directory by changing some registry settings, but this doesn’t seem to work. I’ll work on this more later, as well, to see if I can figure out why, but for now, just put it in your steps that you need to copy this file over manually each time you run through the startup.
If you want to run Maestro (you probably do), the setup process isn’t very obvious.
You have to generate the VM Maestro application download before you can actually download it. All the stuff I could find on line said, “just go to the download sare, and you’ll see the download available.” Well, I didn’t. I had to go to the VIRL Software tab and generate the download—see the screen shots below to see what the process looks like.
When I first ran Maestro, I skipped past the initial configuration screen, so I had to dig though the settings to find where to put things. When I did set these up, it asked me for a username and password—nothing I put in here worked. The setup screen, however, has a space for a default username and password. Apparently, the little dialog box that pops up asking you for a username and password doesn’t do much of anything. I changed the default to the ones in my passwords.tf file, and now it works. Below are some screen shots of the setup as it works for me. You’ll want to create a new profile for the packet cloud—something I’ve not done yet.
Like I said, a lot of this might be obvious to other folks, but I found these bits puzzling. If anyone has questions about this process, or more thoughts, feel free to leave comments below.
Thanks for Sharing Russ. I looked into it and found that it’s too much trouble and may be a waste of time for now (there’s gotta be a better way). I was told that one needs to save and delete their lab or they will be billed continuously. So every time you are going to use the lab, one will have to upload the entire lab. My fear is that if something goes wrong, one can spend hours trying to get everything working again. I’ve worked on labs in GNS3 where all the configs were gone after I saved the lab. Being a Stoic, I would say to myself “Doing it all over again builds good practice and experience” (a bold face lie).
I’ve asked the dumb question many times with no success “Can I get the .ios file and install VIRL on any baremetal cloud server in AWS, Google Cloud etc”?
GBY,
JT
John — thanks for stopping by!
I think the one problem you mention, that you can’t save off your configurations and the like “automatically” is the main problem I see with VIRL on Packet. A coupe of thoughts here. First, if you’re using Maestro, you don’t lose your topology between sessions, just the configurations. I just tried this today — vagrant up, build a topology in Maestro, shut everything down (including Maestro), then bring it all back up. The topology is saved in Maestro. I was afraid I would lose connectivity to the virtual routers, but it all works to that point.
What you do lose is the actual configurations on the devices. This part, I think, might be possible to save by using the “extract configurations” part of Maestro. This isn’t something I’ve played with yet. Of course, you could also build a script that builds the configurations off a unix vm connected to the topology, or you could copy out the configs as text files and save them locally, then copy them back into the topology when you restart, but I’ve not done anything that “big” yet with this, so, again, I’ve not tried any of this. If I play with this more, I’ll write something up on it.
In the meantime, it is a “decent” environment. I can’t get some things to work, but — well, that’s always true.
HTH 🙂
Russ
Hey Russ. When running VIRL on your own computer you still need to do a copy run start on the router CLI. Then in maestro the shutdown mode dialog has a tick box to extract configs.
I haven’t tried it on packet – is Maestro different?
Luke — thanks for stopping by! When you’re running Maestro with VIRL on Packet, you still run Maestro itself on your own machine — so I think it would be the same as running Maestro for a local or other remote install. The difference on Packet is the VM is actually destroyed, so I don’t think copy run start works to save the config, as the VM’s storage space is destroyed with the VM.
🙂
Russ
So if you right click stop simulation in Maestro do you get a pop up asking to close connections and extract configs?
Follow up: “write” on the vrouter will copy the running config to a virtualised startup-config memory space. Maestro can pull from that memory and write it to the .virl file (I believe it’s xml). Next time you start the simulation it copies from the .virl file to the virtualised startup config before starting the router vm.
IIRC if you right click a node from Marstro you can extract startup config at any time if you want to.
I’ve not played with this piece yet to see how it works with Packet on the back end, but I’m assuming it will work the same way as it would with any other VIRL implementation — thanks for the pointer! 🙂
Russ