This is done by making a connection on port em1on the vRE and port int on the vPFE. It’s key to have the connection in place between the vRE and vPFE. 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. Your interfaces will all map to ’emX’ ones and will not be shown as xe-0/0/X in the system. This deployment will only support any layer 3 IP services to, for example, test IP Fabric use cases.

Light mode means that you only boot up a routing-engine image.

The vQFX is supported to run in 2 different versions. 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. So stay away from the more recent Junos 18.x and Junos 19.x vQFX versions to ensure a stable device. 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. I am currently running vQFX with Junos 17.4R1.16 and that is very stable at the moment. 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. This is an aspect of Virtual Chassis technology, which is not supported on the vQFX. Sometimes the vQFX RE comes up in the line card role. The more recent versions of the vQFX are experiencing some issues inside EVE-NG.

I also ran into some aspects of going through the workbook that also would change some small decisions I made when deploying the lab. 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! After having some feedback regarding my previous post on running the JNCIE-DC self-study workbook in EVE-NG.

Ccie eve ng blog