My First Look at Junosphere 3.0


I’ve recently taken on a new day job, where I’ve inherited some Juniper gear that needs to be put into production soon. As long as I’ve been involved with networking, I’ve never worked with Junos. Mostly, I’ve been a Cisco IOS or NX-OS user. While many non-Cisco vendors ape the IOS CLI as sort of a de-facto standard, Juniper does not. From a CLI perspective, Junos is nothing like IOS. That puts me a time disadvantage. In IOS, I can generate a config quickly for routine tasks like access layer port configuration, prefix list creation, QoS policies, routing instantiation, spanning-tree tweaking, etc. Junos? Uh…I’m a monkey looking at a helicopter. Helping me get over the hurdles has been Junosphere.

What is Junosphere?

Junosphere is a cloud-hosted lab environment containing VMs running Junos. This environment lets you build a networking topology and test it out. Conceptually, Junosphere is like GNS3/Dynamips. You manage the Junosphere topology via Java running in a supported browser. (Safari on OS X is a fail. Use Firefox on OS X instead.) You access the topology via a VPN tunnel Juniper provides. Then use your console tool of choice to get at the CLI via telnet.

A couple of key points here.

  • Junosphere is cloud-hosted. It doesn’t run on your desktop. By contrast, an Olive and/or Junos on top of a FreeBSD VM runs locally, and can be integrated into GNS3 if you feel like screwing around with it long enough.
  • Junosphere is pay-to-play. I don’t have details on pricing. I’m lucky enough that my employer bought a Junosphere subscription. Off I go.

How hard is it to get a topology running in Junosphere?

Lighting up a topology is sort of a pain, especially the first time out. I’ve heard that with Junosphere 3.0 release I’m using, it’s easier than it was, and that’s good, I guess. But it’s still sort of awkward. You might be thinking that it should be as simple as GNS3, but there’s a big reason it’s not: you’re part of a multiuser system. Anytime you add functionality, you add complexity.

  • Junosphere is cloud-hosted, and you’re running VMs on that cloudy infrastructure. Therefore, you need to reserve time to be able to run your topology (i.e. you’re competing with every other Junosphere user for finite resources.) That’s not been an issue for me. I go in, make my reservation, and run my topology. Done.
  • Junosphere is set up in the context of an organization with multiple users that can share the account, as opposed to a single instance just for you. Therefore, you can do things like save multiple topologies in various banks and sandboxes, and assign users rights to specific banks, sandboxes, and topologies.

To ease the pain for Junosphere n00bs, Juniper offers a pair of 7+ minute videos that walk you through the process. One video is for “bank administrators” – folks who are the Junosphere account deities for your company. That shows you how to do those pesky administrative tasks. The other video is for “users” – folks who just want to crank up a topology and get some testing done. If you’re about to embark on the Junosphere journey, WATCH THE VIDEOS when the links present themselves. The videos will save you a lot of headaches, because you’ll find that the Junosphere interface isn’t immediately intuitive. This is doubly true if you’re expecting Junosphere to be GNS3 with Juniper branding, because it’s not.

Once you’re past the “how do I use this silly thing” part, Junosphere is reasonably friendly. Getting going consists of roughly the following steps:

  • Create a topology via drag and drop. You can pick from a variety of devices like routers and firewalls. There’s many objects I haven’t tried yet, as I just haven’t needed them to push forward the lab work I’m doing. But anyway…drag icons from the left over to the right. Connect them up. You don’t have any control over which interfaces connect to which interfaces on the other device, but Junosphere clearly shows what’s connected to what when you hover.
  • Save the topology.
  • Assign the topology a reservation. This is required so that you can actually start the thing up. Since you’re actually creating VMs, the Junosphere system needs to track how much you’re going to stress their infrastructure with your topology. Natch, a reservation.
  • Start the topology. This takes a quite a while – several minutes. So don’t go crazy with your topology if you don’t need to. A whole bunch of things happen here. For example – here’s the notes from a simple topology I started this morning with 2 firewalls, 4 routers, and a BGP feed object (basically a route server with the Internet routing table). Note the start and end times – ~6 minutes to fire up.

    15-Aug-2013 10:23 EDT
    Topology is starting…
    Step 1 of 5: Initializing start procedures.
    Step 2 of 5: Allocating resources.
    Step 3 of 5: Starting the topology (using webui0262).
    Starting VMs:
    webui0262-nat (1 of 10 VMs) started.
    15-Aug-2013 10:24 EDT
    CORE-FW1 (2 of 10 VMs) started.
    MPLS-CE1 (3 of 10 VMs) started.
    CORE1_internal_only (4 of 10 VMs) started.
    15-Aug-2013 10:25 EDT
    CORE1 (5 of 10 VMs) started.
    CORE2_internal_only (6 of 10 VMs) started.
    CORE2 (7 of 10 VMs) started.
    15-Aug-2013 10:26 EDT
    EDGE-FW (8 of 10 VMs) started.
    MPLS-CE2 (9 of 10 VMs) started.
    15-Aug-2013 10:27 EDT
    BGP0 (10 of 10 VMs) started.
    Step 4 of 5: Enabling access to the topology.
    15-Aug-2013 10:29 EDT
    Step 5 of 5: Success: The topology is now active.

  • With the topology active, you can join the topology. Joining the topology translates to, “Hey, there’s this thing you made in the cloud. Would you like to access it?” What happens when you click the button to join the topology is that you’re prompted to authenticate again. Then you are prompted to launch the VPN client. Now you’ve got a tunnel up, and can burrow through it into the cloud via telnet to get at the CLI of the devices in your topology. All the IPs and port numbers are listed for your in the Junosphere web management tool. Off you go.

How do I save my topology configurations once I’ve got my lab built?

A really important thing to understand about Junosphere is that your topology configurations only live for as long as (a) the topology is active and/or (b) you made the reservation. Therefore, *before* you either stop the topology or your reservation ends (at which time your topology turns into a pumpkin and shuts down automatically), you must download your topology to your desktop. The Junosphere cloud will not save your configs for you beyond the life of the current active session. Your Junos commits do *not* result in a configuration that will live on forever and ever in that topology.¬†Downloading the topology is easy enough. There’s two steps.

  1. Save the active topology from the “Access Active Topologies” screen. This triggers Junosphere to write all your committed configurations to config files in the cloud that are available to their respective virtual devices for as long as the topology remains active.
  2. Download the topology from the “Manage Topologies” screen. This brings a ZIP down to your local workstation. The next time you activate that topology, you upload that ZIP back to it to get your configurations back.

What does the Junosphere web management tool look like?

Here are a few screenshots to help you visualize what’s going on with Junosphere. Enjoy.

Starting a topology you've created in Junosphere.
Starting a topology you’ve created in Junosphere.
Joining a topology once it's been started.
Joining a topology once it’s been started.
The VPN client that stays open when you join a topology.
The VPN client that stays open when you join a topology.

Is Junosphere worth it?

I can’t comment on the money aspect, because I don’t know what it costs. I will say that Junosphere has let me ramp up my Junos chops very quickly, and do proof of concept for basic routing and firewall topologies. My context is that I’m a network architect that knows what I’m trying to accomplish. For example, let’s say I need to build 802.1q tagged Ethernet interfaces aggregated with 802.3ad LACP. Then I need to build what Cisco would term “sub interfaces” and light up BGP and OSPF adjacencies across them. Then I need to export/import routes between routing domains. Yep – no problem with Junosphere. I could do all of those things, and that was pretty important to me to be able to validate my Junos code.

Now, you can do a LOT more with Junosphere than just basic routing & security sort of stuff. There’s objects there that I haven’t even figured out yet what they do. I believe it’s possible somehow to plumb a real-life host into the Junosphere cloud topology you’ve made (not positive on that, but got that vibe from something I read.) There are “partner” tools that let you do analysis and testing of a topology. My point is that I’ve really, truly just scratched the surface with Junosphere because I’ve had a very specific need I needed it to help me with. So I’ve only gone as deeply as that need required thus far. I can see getting into Junosphere much more as time goes on. In short, *I* think it’s worth it. Junosphere is a powerful tool.

About the author

Ethan Banks

Most people know me because I write & podcast about IT on the Packet Pushers network. I also co-authored "Computer Networks Problems & Solutions" with Russ White.

Find out more on my about page.


  • Hi Ethan,

    Thank you for posting a comprehensive and open comment about Junosphere.

    We want to clarify that the configurations in your topologies can be saved and remain usable even after you shut-down the topology. To do so, commit the topology, wait a few minutes to ensure that the commit process was completed, and then, on teh same window where you start the topology, click “save”, this will keep the new config file on the topology and enable it for future use. You can make multiple copies of the same topology so you can keep control of your topology versions.

    • Thanks, Pilar. I’ll investigate this further. What you’re describing wasn’t my experience, but I’ll definitely try it again. It’s worth noting that the Junosphere documentation thats’s in the right sidebar of the site describes the process I outlined in the article here, unless I’m overlooking something. Here’s what I’m referring to.

      “To save your Junos OS .conf configuration changes:

      Use the commit command in Junos OS while the topology is running to save changes to a configuration file.
      Wait 5 minutes to ensure that the commit command is fully executed in all of the router databases.
      Click Save or Save As to store the configuration information of all of the routers in the topology to Junosphere.
      Select Topologies>Manage Topologies.
      Select your topology and click Download topology in the upper left corner of the Topologies section to download the zipped topology file set from Junosphere to your local PC.
      Unzip the zip file. This results in a topology.vmm file and a directory with one or more .conf files in it.
      Edit each .conf file, removing the interface ge-0/0/0 configuration.
      Save the .conf files.
      Zip the topology.vmm file and the directory with the .conf files to form a .zip file.

      The next time you upload the .zip file and start the topology, the new configuration is implemented. ”

      I apologize if I missed something here. I’ll work on Junosphere more as time permits, and blog more to correct anything I got wrong. Thanks for the follow up – lots of feedback from Juniper folks to this piece.


Most people know me because I write & podcast about IT on the Packet Pushers network. I also co-authored "Computer Networks Problems & Solutions" with Russ White.

Find out more on my about page.

Subscribe via Email

Receive complete, ad-free posts in your inbox as I publish them here.