JunOS Service restart via cronjob

Some days ago we had trouble on one of our QFXes where the jdhcpd deamon would consume 100% CPU and “crash” – resulting in users not getting IP’s anymore.
While TAC is still investigating, I made a quick Workaround for this – the DHCP-Sheriff 😉


This Script restarts the Service if the load of the Service is above 1% (adjustable) – this can be easily adopted to other services and thresholds.

1.) Login as root and in shell type: vi /var/tmp/dhcp-sheriff.sh

2.) Press “i” and paste the above lines, followed by “[Esc-Button]”. Save and Quit with :wq

chmod +x /var/tmp/dhcp-sheriff.sh

crontab -e
0 */8 * * * sh /var/tmp/dhcp-sheriff.sh (executes it every 8h)


crontab -l
0 */8 * * * sh /var/tmp/dhcp-sheriff.sh

6.) in cli check after job has finished to run via show log dhcp-sheriff.log


Feel free to use this to your advantage – hopefully this will be a workaround for you in urgent-times until a fix is released.
This is only a workaround – do not use this in production for a long time / use at your own risk.

OSPF between a vSRX-Cluster and a standalone vSRX over vQFX on EVE-NG

I promised to deliver this and here it is: OSPF over vQFX 😉
These days I lab a lot with EVE and I love it more every day – the possibilities are endless and the Labs are very very quick configured and running. With 2 new CPU’s my EVE now runs with decent Speed so compared to VMware ESX 6.0 there is no extreme performance difference anymore. I can live with that. Since D63 on the vQFX is running very stable and smooth I thought of this small OSPF Lab – I will add more “Quick-Labs” in the Future.

The SRX in Clustermode runs very well on EVE – however there is an optical error. If you build a Cluster, the interface mappings on EVE are completely wrong. This is due to the SRX getting a new interface (em0) as second interface Card – so if you select ge-0/0/0 in EVE, you really select em0.

But why is that you will ask? The answer is simple:
EVE is not aware of Cluster-Naming or Cluster Interfaces – so you have to think twice, what you have to select – I needed Wireshark to see what happened…
From top down the first Interface in EVE is fxp0, the second Interface is em0, the third is ge-0/0/0 or 7/0/0, the fourth is ge-0/0/1 or 7/0/1 and so on (see the Table below from Juniper):

Once I figured that out I could successfully build the Cluster (this time fully working, not just partially) and here is the Lab:



vSRX-NG5+6 (the SRX-Cluster):



vSRX-NG7 (the standalone SRX):



Lab-C01 (Coreswitch 01, vQFX running 15.1X53-D63.9):



Lab-C02 (Coreswitch 02, vQFX running 15.1X53-D63.9):


Download this Lab for your EVE here: (Size 16kB, zip-Archive)

Running vQFX 15.1X53-D63 on EVE (KVM)

The KVM version of the latest vQFX routing engine VM (vqfx10k-re-15_X53-D63) seems to be broken. If you try to run it, it will crash with a kernel9 panic and will never boot up completely.
However you can “cheat your way around this”:

1.) Simply download the Vagrant .box file of the D63 RE.
2.) Extract the .box File with 7zip – you will extract a file with no extension.
3.) Extract this file again and “magically” a file called packer-virtualbox-ovf-1491593710-disk001.vmdk will appear.
4.) Upload this to eve, convert it to hda.qcow2, fix permissions and run it – voila: D63 on EVE.


PFE is the same (no D63 Version available, since the PFE is not tied to a Software Version).

It’s always a good idea to dig around the provided Files from Juniper once something breaks 😉

Download the Files here: http://www.juniper.net/support/downloads/?p=vqfxeval#sw

EX2200-C and JunOS 15.1R6.7

Today I installed the 15.1R6.7 on my EX2200-C at home – this Release fixed one of the most annoying Bugs –> The Temp-Sensors are now “seen” again and the red-alert is gone.

By setting GEPHY1 to 0 degrees C the Alarm has no intention to cry – and finally my Juniper-Rack is green again – thanks Juniper 🙂

In the next days I will lab some more with this release – I expect it to be “recommended” ASAP by Juniper because 99% of our Customers didn’t move from 12 to 15 due to this nasty optical bug. Of course there are also some problems with dot1x in 15.1R5 but that’s a different story 😉

EVE-NG and the vQFX

Just wanted to give you a short update regarding my attempt to run the vQFX on the latest eve-ng.

Here is how I managed to run it:

1.) Connect to your eve-ng server via ssh and create 2 folders according to the eve-ng naming scheme (important or your vQFX will not be recognized!)

2.) Copy your vmdk-images to the eve-ng server via scp or sftp (I used /tmp as directory)

3.) Convert your harddisks:

4.) Run the script to fix your file-permissions:

5.) Go to your eve-ng webinterface and create 2 nodes inside your lab.
Leave the settings like CPU and RAM at the default.

6.) Enjoy your vQFX 10k on eve-ng 🙂

JunOS ZTP with Windows DHCP Server (SLAX-Method)

Recently I’m working on some SLAX-Scripting due to a Customer-Project.
I really start to like SLAX, since it can gather a lot of your Switches Data on the Device itself.

I am writing a quick How-to for using SLAX to automate your ZTP with the Windows DHCP-Server.
Most Customers use Linux DHCP-Server since you can specify Options and “Configs” for every IP / Device.
With the SLAX-Method you no longer need to configure your DHCP-Server once a new Device comes up – you just have to provide the config and that’s it – highly dynamic, highly hardened, highly customizable – stay tuned for more Infos.

EX3300 Q-in-Q implementation

Today one of my Customers asked me to implement Q-in-Q on 2 EX3300-Switches.
Since more and more people asked me on the Forum how I did that, I decided to make this an Article.
Most of the J-Docs only mention parts of this config – so here you have a fully working Q-in-Q config for non-ELS.
If you are interested, I can share Q-in-Q also for ELS.

The Setup is as follows:
2 EX3300 (Q-in-Q Switches)
1 EX3300 (Transfer-Switch)
1 EX3300 and 1 EX2200 (Client-Switches)

Topology (click to enlarge):

So at first in configured Q-in-Q (of course if this is productive you need to install a license):

In the next step, I configured the Transit-Switch. This Switch must not be aware of any Q-in-Q or Customer VLAN’s at all:

After the Setup was completed, I tested it by adding 2 Switches as “Client-Devices” pinging each other in vlan 10:

Hopefully this will help some of you in configuring Q-in-Q on EX3300 (non-ELS). If you have any Questions or Remarks feel free to comment on this Article. The Switches I used all used JunOS 12.3R12.4


This Article is now also officially listed in Junipers TechWiki (http://forums.juniper.net/t5/Switching/How-To-Configuring-Q-in-Q-Between-Two-EX3300-Devices/tac-p/304182#M32) 🙂