Rick Mur

Limitless Networking

JNCIE-DC Lab Experience

After plenty of hours of studying and labbing the wide ranging topics on the JNCIE-DC blueprint, I took the JNCIE-DC lab exam and passed! I can proudly say I’m JNCIE-DC #389. In this conclusion of the previous JNCIE-DC blogs about my lab setup and about the remote lab environment, I will talk about my experience of taking the lab and how I’ve prepared.


As I’m working with different cloud provider customers in my daily job it really helped in preparing for this test. Being exposed to the platforms and technologies used gave me a head start, but after really starting to lab the different topics I really felt I had a long way to go. I was also a champion in delaying my actual start of preparation. After committing to the goal of passing the test in Q1 of 2021 I really picked up the pace and started studying multiple nights a week and came into the flow I like to be when preparing for a lab exam.

JNCIE-DC self study workbook

The Juniper Education self-study workbook for the JNCIE-DC lab is by far my most used resource for the lab. This will prepare you for 95% of the test. Note that it does not cover 100% of the topics and you will need to read documentation and have a deep understanding of the technologies on the blueprint of the test.

Examples of this are working with Class of Service configuration on QFX5100 platforms, as the lab only works on vQFX devices which are based on a virtual Q5 PFE rather than a Trident2 chip as used in the QFX5100. This means you really have to be aware of the physical limitations of the platform when applying Class of Service configuration.

The same goes for Virtual Chassis Fabric. Again a feature only supported on QFX5100 (and QFX5110/EX4300), not on the vQFX.

When working through the labs of the workbook you will find that some solutions will not have much explanation other than the correct configuration. Sometimes this made me doubt my own solution of which I was sure was correct as well. Then it really helps by taking the documentation and checking it by yourself to know if your variant is just as right as the configuration in the workbook is.


My Dell R730 server running bare-metal EVE-NG Pro was a life saver during the preparation. The performance was amazing and I could spin up as much virtual resources as I wanted to test various topologies.

Juniper Documentation

I did not read books as a preparation, but you do need a solid understanding of routing protocols, MPLS and EVPN. To brush up on all the knobs and features I read parts of the Juniper documentation which has excellent sample configurations explaining what’s needed and why.

Taking the lab

As I took the lab in March of 2021. The Juniper offices are closed because of COVID-19 and the lab exam is conducted remotely. I’m fortunate to have a dedicated home office room that I could close and be isolated, as is required according to the lab policy. For all other requirements that your PC and room have to comply with can be found in my previous blog about that.

First be prepared that the JNCIE-DC lab in 2021 is still an 8 hour exam and not a 6 hour exam that other tracks already are.

Early morning on the day of your lab, you will receive an e-mail with an attachment for the Secure Exam Browser. This is a kiosk application that ensures a fully isolated environment where you will access the lab task document, documentation and a remote desktop environment with access to the equipment. Note that you are not able to print the tasks or diagrams of the lab so if you have a widescreen or a dual monitor setup that is a big plus! On my ultrawide monitor I could fit the topology diagram, tasks and remote desktop with notepad and securecrt open next to each other.

You will join a Zoom call where you will need to have (and keep) your webcam enabled as well as your microphone (do not go on mute). On the time mentioned in the e-mail your proctor will join the Zoom session and put you in a separate room where only you and the proctor are in. You will see the proctor jump in and out of your room at random times to check on what you are doing via your webcam, audio and the screenshare that is constantly running.

To access the devices you will open SecureCRT and see sessions to all devices both over out of band management (SSH) and over Console. The sessions will even automatically login so Juniper makes your life easy there. I did have to get used to some latency on the sessions as it felt like the remote desktop was hosted in the US and I’m based in Europe, so having a 150ms-ish latency on the connection does need some adjusting when you are typing fast.

If you want a break to grab a drink or go to the toilet, raise your hand on the Zoom call to attract the attention of the proctor and ask for permission before leaving your desk. The official time for lunch is 1 hour, but you are not allowed to be away for that time of course. The proctor will ask you to eat your lunch in front of the camera at your desk and you can take some time to rest. My proctor was kind enough to allow me to get back to work after about 20 minutes and gave me my official time to finish the exam.

Time management

Managing your time is an absolutely crucial part of taking a lab exam. During my preparation I really struggled initially to finish a decent sized lab on time, but after pushing hard on speed and concentrating I was able to finish the super labs in the workbook in under 4 hours. When I take the lab I’m always very aware of the time I spend on each section or part of the test. I keep track of that by putting timestamps in a text file and which part I finished at that time. The way I like to work is go trough the tasks as quick as I can and finish them so I have a lot of time left for reviews.

When I returned to work after lunch I was about 80% done with the tasks and could finish all of them in about 30 minutes so I had plenty of time left. Now I have to admit when I do these lab exams, my typing speed has increased a lot over my normal speed as I’m trained to work on these configurations for hours. With over 3 hours left on the clock I went back to the very first task and I try to read it like I have never read it before to try and trick myself into coming up with the solution again. Overall I made 2 small changes to the configuration that I don’t know if they made an impact, but to me they felt like the better answer to the task.

With about 30 minutes left I felt like I checked everything twice and did a calculation on how many points I was certain of and how many I had some kind of doubt about. The passing score is not known, but I assumed it’s around 78-80%. With having more then enough points based on my own verification I told the proctor I was finished.


The official waiting period is ‘up to 5 working days’. For my result to come in it actually took those 5 working days so a full week after my lab attempt I received the e-mail that I passed!

This JNCIE-DC exam is definitely a tough one and I feel lucky I was able to pass this one at first attempt. The complexity lies mainly in the fact that everything builds on top of each other and a mistake in one of the layers impacts reachability across pretty much the entire exam. It’s absolutely crucial to be very exact on details of the tasks, but also to not overthink them! Do exactly as the task says within the constraints you are free to choose the solution you want. The exam is not there to trick you, but just to test you on you being an expert!

JNCIE-DC remote lab exam resources

Due to the COVID-19 pandemic the exam centers of Juniper are at time of this writing closed for external visitors. Fortunately the Juniper Education team did a great job and made JNCIE lab exams available from your own home!

Now this does impact how you make the test and also what resources you have available to you during the test and also what you are allowed to use. In this blog I will share how the testing environment works and also exactly what documentation you have available for reference.

How do I access the exam?

The Juniper Education team did a good job in preparing candidates for a remote lab attempt. When you schedule your lab, you will receive an e-mail with extensive instructions on how to prepare yourself for the exam and even include a link to access a demo environment to make yourself aware with what you will be faced with on the day of your actual attempt. The testing environment gives you access to some Juniper documentation. It will give you access to a vSRX to test CLI access and your keyboard mapping in the remote desktop tooling. The main goal is to prepare your computer for the test as well.


  • Windows PC or Laptop (Linux and Mac not supported!)
  • External monitor is allowed, I believe even multiple external monitors
  • Wired or wireless mouse
  • Wired external keyboard or built-in laptop keyboard (wireless keyboards are not allowed)
  • No headsets or music listening is allowed
  • Stable internet connection with sufficient bandwidth for the remote desktop access and a webcam stream
  • Zoom Desktop app
  • Empty walled room/office. Nobody can come in during your exam.
  • Clean desk, nothing should be in reach of your hands
  • No paper or pens allowed
  • Dry erase board is allowed on your desk to take notes. You will need to show it’s empty when you start and that you completely wipe it clean after the exam is finished. This can be a board behind you on a stand or on the wall, as long as it’s visible to the webcam.

The exam will be delivered through an application called Safe Exam Browser (SEB). This will block all your other apps on your PC and just open a browser screen, remote desktop session and Zoom call to the proctor. A dedicated file to join the SEB session will be e-mailed to you just before the exam starts.

When the remote desktop session opens, you will have access to the following apps

  • SecureCRT with bookmarks to the devices for your exam
  • Notepad++ to take notes and store configuration snippets you are working on
  • PDF reader for viewing documentation

The remote desktop session will use your own screen resolution, so if you are fortunate to have a big monitor (I’m using a 34″ ultrawide 3440×1440), it’s possible to have the exam tasks, secureCRT window and notepad++ window in 3 columns on the screen. Which I feel is the best set-up for me, to read on tasks, take notes in notepad and type in the commands on the CLI.

For further details on the exam environment, please read this FAQ from Juniper very carefully as it will make your preparation for the big day better. Basically the same rules apply as when you would take the test on-site, it’s now just in your own home.



One of my concerns was how the documentation is accessed. Of course to pass this exam, you need to know 95% of the configurations by heart. For those last few small knobs or complex things it is very welcome to have access to the documentation. When accessing the documentation you can either open the documentation folder on the virtual desktop and open the PDFs using a PDF reader. But you will also have access to the PDFs using a browser session that is available within the SEB environment. Please know that you do not have access to the documentation website, only the PDFs.

To make it easier, I asked the Juniper Education team what is available to the candidates. Please be aware that the list mentioned below is different for all JNCIE lab exams. In this case it’s the documentation available to JNCIE-DC candidates.

The Juniper Education team shared the list of PDF filenames with me and I have permission to share this on my blog. I did not receive the actual files, so I have linked these PDF names to what I believe are the documents on the Juniper website, but that is my own best guess and is not officially confirmed!













Good luck!

I hope this helps explaining the JNCIE remote lab experience and specifically showing the documentation that is available to you during the test. Good luck on your attempt! I’m curious to learn how you feel the remote lab works and of course if you passed!!

Happy labbing!

JNCIE-DC lab in EVE-NG tips and tricks

After having some feedback regarding my previous post on running the JNCIE-DC self-study workbook in EVE-NG. I wanted to share some of the most common questions I personally experienced while using the lab and general things to be aware of and some tips!

I also ran into some aspects of going through the workbook that also would change some small decisions I made when deploying the lab.

vQFX version

The more recent versions of the vQFX are experiencing some issues inside EVE-NG. Sometimes the vQFX RE comes up in the line card role. This is an aspect of Virtual Chassis technology, which is not supported on the vQFX. When the system is in line card role, it means it does not maintain an editable configuration as that would be done by switches in the VC with Routing Engine role.

I am currently running vQFX with Junos 17.4R1.16 and that is very stable at the moment. In the JNCIE-DC lab environment a much older version is used, so for feature parity is not an issue and stability matters most right now. So stay away from the more recent Junos 18.x and Junos 19.x vQFX versions to ensure a stable device. I have gotten them to work plenty of times, but it’s not stable enough and I don’t want the lab to be in my way when I’m studying for an exam.

vQFX data-plane / em1 interface

The vQFX is supported to run in 2 different versions. ‘light’ mode and ‘full’ mode. Light mode means that you only boot up a routing-engine image. This deployment will only support any layer 3 IP services to, for example, test IP Fabric use cases. Your interfaces will all map to ’emX’ ones and will not be shown as xe-0/0/X in the system. To utilise the virtual PFE, the full potential of the vQFX and the ability to run layer 2 bridging and EVPN services you will need the ‘full’ version which requires to deploy a second VM for each vQFX which will run a virtualised version of the Q5 PFE.

It’s key to have the connection in place between the vRE and vPFE. This is done by making a connection on port em1 on the vRE and port int on the vPFE. On the vMX the connection is similar, but once made in EVE-NG the configuration is not visible in Junos. On the vQFX the IP addressing between these 2 VMs is required to be in the configuration, otherwise you will lose the connectivity to the vPFE and that will result in losing the xe-0/0/X interfaces being visible from the CLI.

It’s easy to miss this out, because the vQFX boots up with a full list of interfaces with regular ethernet-switching configuration. During your labbing it’s easiest to delete the entire interface stanza before starting, but by doing this you will also delete the em1 interface which handles this vRE to vPFE communication and needs to be configured with the IP address The em0 interface is similar to the fxp0 interface on vMX and that is your direct connection to the virtual RE or the out of band management interface.

When I start working on a new vQFX I immediately delete all interfaces, but make sure you put the em1 configuration back! Along with maybe your management subnet configuration!

delete interfaces

set interfaces em1 unit 0 family inet address

Management subnet

The JNCIE-DC workbooks consists of many chapters and many parts within those chapters. For each part in a chapter there are separate starting/initial configurations as they typically do not build on top of each other. This means you will be loading a lot of new configurations during your labbing.

Copying and pasting configurations over the virtual console connection that EVE-NG sets up to the serial port is typically not the best idea. Unless you delay the speed that your terminal emulator pastes information in the window.

To also get the best connection to your devices. I would recommend using the out of band management interfaces (em0 on vQFX and fxp0 on vMX) to connect to the devices. It gives me the most stable connection to the devices and does not mind pasting in big chunks of configuration.

The initial configurations of the JNCIE-DC workbook are set-up with an out of band management subnet of I’m using a different subnet for my lab devices VLAN, so when I open a new initial configuration I have to do a find-replace action. You could also make your life easier by using the subnet in our lab if that’s an option!

The SSH access to the devices is really helpful again to quickly load configurations, which I not only use for the initial configs, but also for copying and pasting parts of config between devices during the labs.

Initial configurations

Take good care of loading initial configs for each part. EVE-NG is not the best at managing this on Juniper devices, because it expects a device to be logged in. Which a Juniper device never is. You always end up in a log-in prompt.

I found it too much of a hassle to work on updating the configs, as each chapter has multiple initial configs for the various parts of the chapter. This means you will be loading and replacing a lot of configurations during your work in the book.

I find it useful to save my final configs for each part as well. Some people like to log all the command outputs to a text file, but I feel that’s a bit much when you’re working on a lot of devices and are typing a lot. Saving final configs does help in checking your answers in the book at a later time. I typically work on it in the evening and then only have time to finish a few parts of a chapter. The next day I’ll go back and verify my work in the book and review my configs in text files.

When loading in the initial configurations. It’s important to keep in mind your management subnet on the fxp0 and em0 interfaces, so that you don’t lose connectivity after a commit!

Loading in a brand new configuration on a Junos device is fortunately very easy. Just use the load override terminal command and paste in your new config. After a commit your device has a complete new identity!

Copy/Paste between devices

When working through the chapters. You will find that a lot of configuration will be similar on multiple devices. Especially routing protocol knobs such as authentication or policies. I find it very useful to do configuration on one device and then using a show | compare to verify. Copying the output of that to a new device works really well by using the load patch terminal on the other device to load in the differences.

I also find it very useful to have a text editor open next to me. I use Sublime Text 3 with the Junos plugin so it highlights the syntax. Especially configuring a lot of BGP peers (like in an IP fabric setup), it helps keeping the configuration consistent and only a few IP addresses will change between devices. Being able to quickly change this and then copying it over to the other device saves a lot of time and potential errors!


As mentioned before, the parts within the chapter do not build on each other. This means you have to wipe and reconfigure the devices before moving to another part of the workbook. I’ve experienced a few times that after I wiped the config and reconfigured the device for the next part (load override) that the devices can behave strange. Which would result in not having IP connectivity on links. The problem is that you will be configuring something and you want to verify that what you did is correct. So if verification fails, it makes you doubt your own config. In the case of reconfiguring the devices multiple times, I’ve seen it happen that sometimes the config is not correctly applied in the vPFEs. This means that the configuration does not reflect the actual implementation in the device. To get this fixed a full reboot of both the vRE and vPFE would solve this!

Flapping peers

Again similar to the previous point. I reset the configurations to a new part of the chapter and after verifying IP connectivity I thought everything was OK, but after configuring BGP. I experienced weird issues with flapping peers. Every 1 to 2 minutes all my BGP peers would suddenly reset. Even after a reboot of the virtual appliances!

I abandoned troubleshooting initially, because it was already late at night. I powered off my server and powered it back on again the next day. After the appliances were all running again. The problem was gone and my config hadn’t changed at all! So even if a reboot doesn’t fix your issue try to close the lab and re-open it in EVE-NG or reboot your entire server to fix issues of which you are (almost) certain they are not related to your configs!

EVE-NG Client Pack

As a few final thoughts I’d like to highlight some of the excellent features that EVE-NG brings to the table. The first I’d like to mention is the client pack that EVE-NG offers for all desktop operating systems. Logging in on the native console (not the HTML5 one, which I only use when I’m not connected of EVE-NG offers you the ability to open console sessions to your devices using your favorite terminal emulator. Which to me personally is iTerm2 on macOS and SecureCRT on Windows.

On iTerm2 ensure you select the setting to have iTerm2 be the default ssh:// url handler in the profile settings.

On Windows if you want SecureCRT to be used as default app to open console windows. The EVE-NG Client Pack installs scripts to make this easy. Go to C:\Program Files (x86)\EVE-NG\ and open the .reg file that reflects either the 32-bit or 64-bit version of SecureCRT which is abbreviated with sCRT. After running the reg file, SecureCRT should open automatically when opening console windows. If it does not search in your start menu for Default Apps, then go to Choose default apps by protocol and select SecureCRT as the default application for the TELNET protocol.

By default on Windows each session you open on EVE-NG will open a new window of SecureCRT. Where most people will prefer new tabs. To change this go into your SecureCRT config directory which is usually found under: C:\Users\<username>\AppData\Roaming\VanDyke\Config and find the Global.ini file and change the following line:

D:"Single Instance"=00000000

and update to

D:"Single Instance"=00000001

Now all new windows will open as tabs in the same window.

EVE-NG Miscellaneous

Depending on your server the bootup times it could take a very long time to boot all the virtual appliances. Sometimes it could feel that they are stuck, but be patient is the only solution to that (or faster CPU’s of course 🙂

Finally, make sure you update your EVE-NG installation using standard apt commands. Recently a vulnerability was discovered in one of the modules that EVE-NG uses so always make sure you are running an up to date installation. Fortunately that’s very easy to do!

Happy labbing!!

« Older posts

© 2024 Rick Mur

Theme by Anders NorenUp ↑