Category / Juniper Related

For all docs, guides and misc info related to Juniper.

by Ben

Installing and Running vJunos-Switch on Proxmox

TL:DR Juniper have been kind enough to release vJunos-Switch as a free product.

If you’re here then you probably want to skip to the chase of finding out how to run this on a Proxmox Server, so let’s get started in installing and running vJunos-switch on Proxmox.

 

Download the .qcow2 image from https://support.juniper.net/support/downloads/?p=vjunos

Note: change the file name where appropriate below if a newer version is available.

1) SSH into your Proxmox server.

2) Create a qcow directory in /var/lib/vz/template

mkdir /var/lib/vz/template/qcow

3) Upload the .qcow2 image to /var/lib/vz/template/qcow (sFTP/SCP)

4) Create the VM config file, you’ll need to find the next available VM ID on the host. For me that was 120 but you should check.

touch /etc/pve/qemu-server/120.conf

5) Assign the .qcow2 image to the VM, you’ll need to adjust local-zfs to whatever datastore you wish.

cd /var/lib/vz/template/qcow/
qm importdisk 120 vjunos-switch-23.1R1.8.qcow2 local-zfs

 

6) Replace the config of the previously-created 120.conf

nano /etc/pve/qemu-server/120.conf

Contents:

 

args: -smbios type=1,product=VM-VEX -chardev socket,id=serial0,port=7890,host=0.0.0.0,server=on,wait=off,telnet=on -device isa-serial,chardev=serial0
boot: order=virtio0
cores: 4
cpu: host
memory: 8192
meta: creation-qemu=7.2.0,ctime=1682364130
name: vjunos-switch-2
net0: virtio=FA:BB:50:F5:DD:C1,bridge=vmbr0,firewall=1
net1: virtio=3E:4E:80:80:15:45,bridge=vmbr0,firewall=1
net2: virtio=66:E9:23:49:6F:C6,bridge=vmbr0,firewall=1
net3: virtio=FE:B6:81:8F:85:EE,bridge=vmbr0,firewall=1
net4: virtio=46:22:4C:F2:AB:50,bridge=vmbr0,firewall=1
numa: 0
ostype: l26
scsihw: virtio-scsi-single
smbios1: uuid=b60b0b27-593c-42fd-a2ac-a8702cb0415e
sockets: 1
vga: none
virtio0: local-zfs:vm-120-disk-0,iothread=1,size=32524M
vmgenid: 0b30be1d-92b6-443c-a416-725dbcfa14d5

7) Power up the VM, and then telnet to localhost port Start VM and, from the Proxmox Host, telnet to localhost on 7890

It’ll take a couple minutes for Junos to fully boot and there will be some inevitable messages that look like errors, but you should eventually get to the cli prompt.

 

 

 

For more misc Juniper blog posts, see here

by Ben

Clear your switches properly! Failed “system archival” transfers are kept on the device even after running a zeroize.

Just a very quick one here as I recently came across some unknown configs in our archival backup server after configuring some refurbished switches for “system archival” and committing.

I found config backup files had been transferred which belonged to the previous owner!

The switches were zeroized prior to provisioning them on our network.

When using the system archival feature in Juniper and the transfer fails, the config is left in /var/transfer/config, files in here remain even after a “request system zeroize”. Once the switch is configured for system archival again then all files in that directory are pushed to the configured destination.

So, before selling or discarding any Juniper equipment, remember to check /var/transfer/config if System Archival has ever been used within your configuration.

by Ben

Monitoring Virtual Chassis VCP Ports via SNMP with Juniper QFX (and EX!)

For some strange reason, the vcp-snmp-statistics statement is hidden on the Juniper QFX platform – (if anybody knows why, please do tell!). This means  your individual virtual chassis VCP port statistics aren’t exposed in it’s entirety, which is pretty awful as monitoring VCP port errors are vital in virtual-chassis setups.

{master:0}[edit]
ben@qfx0# set virtual-chassis vcp-sn
                                                  ^
syntax error.
ben@qfx0# set virtual-chassis vcp-sn
                                                  ^
syntax error.ben@qfx0# set virtual-chassis vcp-sn?
No valid completions
{master:0}[edit]
ben@qfx0# set virtual-chassis vcp-snmp-statistics

{master:0}[edit]
ben@qfx0#

After committing changes, you should see the following in the logs, and likewise see more ports listed in your monitoring software of choice i.e. LibreNMS, Solarwinds, Zabbix etc.

Dec 27 10:59:12  qfx0 vccpd[1797]: Member 0, interface vcp-255/0/53 came up
Dec 27 10:59:12  qfx0 vccpd[1797]: Member 0, interface vcp-255/0/52 came up

 

 

by Ben

Switch Power Usage

Just a selection of very quick and simple power consumption testing of various Juniper and Cisco devices to check the switch power usage.

Juniper EX4200-48T – No Ports Connected – 126w – Single PSU Connected
Juniper EX4200-48T – No Ports Connected – 150w – Dual PSU Connected
Juniper EX4200-48T – 48 RJ45 Ports Connected – 210w – Dual PSU Connected

Can therefore determine that the PSU in an EX4200 uses ~24w and that each RJ45 port uses ~1.25w each.

Juniper EX4300-48T – 48 RJ45 Connected – 125w – Dual PSU Connected

Cisco Catalyst 2960-S-48 – No Ports Connected – 60w – Single PSU

by Ben

Juniper Notes – QFX Related

Just a very quick few Juniper QFX related notes, probably more for personal future reference than an actual guide here, but may be useful to know!

Juniper QFX stuck in “Fabric with mixed devices” mode.

Typically a QFX comes from the factory in “Virtual Chassis with similar devices” mode when running “show virtual-chassis mode”. However, I discovered that one newly received QFX was showing in “Fabric with mixed devices” even after factory defaulting and even with a “request system zeroize”.

It’s a very simple fix but not particularly well documented and certainly a head scratcher and took longer than I’d like to admit to discover especially when expecting a factory reset to actually… reset to factory default.

request virtual-chassis mode fabric mixed disable reboot

JUNOS Host Software differs to actual Junos on the device.

You might find that the “JUNOS Host Software” differs to the actual Junos version on the device.
This is common in the Juniper QFX5100 and EX4600 for example where the Host OS is not automatically upgraded however not exclusive to those devices.
Although it is not necessary for Host and JunOS versions to match (unless otherwise specified in release notes), you may like to have them matching for uniformity.

To resolve this you simply need to add the “force-host” parameter to the end of your “request system software add” command. For example:

request system software add /mnt/jinstall-host-qfx-5-17.2R2.8-signed.tgz no-validate force-host

An excerpt from a Juniper KB here:

NOTE: On QFX5100 and EX4600 switches, the Host OS is not upgraded automatically, so you must use the force-host option if you want the Junos OS and Host OS versions to be the same.
However, pay attention to these notes regarding Junos OS and Host OS versions:

The Junos OS and Host OS versions do not need to be the same.
During an ISSU, the Host OS cannot be upgraded.
Upgrading the Host OS is not required for every software upgrade, as noted above.
If you are downgrading from Junos OS Release 14.1X53-D40 to any release earlier than 14.1X53-D40, you must use the force-host option or else the switch will issue core dumps.

More reading here.

For more Juniper related notes, see here.