Power-consumption of mostly Juniper EX switches

2019/09/19 hardware, meh, network

Measured using Voltcraft Energy-Logger 4000; when JunOS is fully booted. No cables, no SFPs, no POE consumption.

  • Juniper EX3400-24T 30 watt
  • Juniper EX3300-24T 30 watt
  • Juniper EX3400-48T 40 watt
  • Juniper EX4200-24T 90 watt
  • Juniper EX4200-24F 85 watt
  • Juniper EX4200-48T 120 watt
  • Juniper QFX5100-48T-6Q 175 watt
  • Dell Force10 S4810 110 watt
  • Dell R430 (dual 2650v4, 256GB) 70 watt
  • Dell R430 (dual 2650v3, 96GB) 130 watt
  • Dell R630 (dual 2697A, 512GB) 220 watt

Convert Juniper zone-based firewall objects to global objects

2018/10/24 vSRX, µpdate

show configuration | display set | save /var/tmp/config.set
start shell user root
grep address-book /var/tmp/config.set | awk '{ $4=$5=$6=""; $3="address-book global"; print $0 }' >> /var/tmp/loadme
grep address-book /var/tmp/config.set | grep -v address-set | awk '{ $1 = "delete"; $NF=""; print $0; }' | uniq >> /var/tmp/loadme
grep address-book /var/tmp/config.set | grep address-set | awk '{ $1 = "delete"; $NF=$(NF-1)=""; print $0; }' | uniq >> /var/tmp/loadme
load set /var/tmp/loadme
show | compare
commit check

µpdate: Juniper vSRX 18.1R1 on Opteron 4228 HE and ESXi 6.0.0

2018/07/12 vSRX

Tonight I wasted much time on ovftool because it’s parameters are order-sensitive. FYI I think it’s alphabetic or do –help and follow that list in that order on the CLI. My final one-liner:

ovftool version 4.0.0
 /vmfs/volumes/WD_2TB_RAID5/vmware-ovftool/ovftool --acceptAllEulas -ds=WD_2TB_RAID5 --name="Ewald - vSRX01 - Olivia" --net:"VM Network"="Ewald-WAN" "" "vi://ewald:mypass@localhost"

Then I ran into a problem where the KVM guest got into a boot-loop. I turns out Juniper rigged the KVM host with a watchdog to restart the KVM guest instances upon failure. We can suppress these ‘notifications’ however.

Use Ctrl+ALT+F2 to get a console and login using root (no password), then vi /etc/rc.local and add before the last exit line

echo 1 > /sys/module/kvm/parameters/ignore_msrs

and reboot!

µpdate: little bit of OSPF

2017/11/09 network, µpdate

ewald@george# show interfaces | commands | grep ‘description\|cost’ | grep vti
set vti vti0 description ‘’
set vti vti0 ip ospf cost ’15’
set vti vti1 description ‘’
set vti vti1 ip ospf cost ’20’
ewald@lucas# show interfaces | commands | grep ‘description\|cost’ | grep vti
set vti vti0 description ‘’
set vti vti0 ip ospf cost ’15’
set vti vti1 description ‘’
set vti vti1 ip ospf cost ’20’
ewald@alivia# show interfaces | commands | grep ‘description\|cost’ | grep vti
set vti vti0 description ‘’
set vti vti0 ip ospf cost ’20’
set vti vti1 description ‘’
set vti vti1 ip ospf cost ’15’
ewald@olivia# show interfaces | commands | grep ‘description\|cost’ | grep vti
set vti vti0 description ‘’
set vti vti0 ip ospf cost ’15’
set vti vti1 description ‘’
set vti vti1 ip ospf cost ’20’

vti0 should be thought off as the horizontal lines, vti1 is the cross in the middle, left and right are location one (olivia and alivia) and two (george lucas). If a two third routers were to be connected to both routers on the same location respectively; they would receive equal metrics from announcements over both horizontal lines. in case of failure the remaining horizontal link would assume all traffic, once that fails the cross is ECMPed. set vti0 on lucas-alivia to 30 and the upper horizontal link becomes prefered path, in case the upper link fails it would ECMP over both vti1 links and finally use the backup link between lucas and alivia.

How I backup my VyOS machines using FreeNAS

2017/02/26 edgeos, FreeNAS, vyatta, vyos , , , , , , , , , ,

Seed VyOS / EdgeOS

We start by seeding the routers with a script to insert a ssh-key used by FreeNAS to access to box. We make add the backup cronjob and make sure it runs on a daily-basis. We also move the apt daily-cronjob to the root-homedirectory as it seems to unnecessarily slow things down. Make sure to replace your key in the script by your own. I’m using the backup user on VyOS (native user).

mkdir /home/backup
mkdir /home/backup/.ssh/
mv /etc/cron.daily/apt /root/
chown backup:backup /home/backup -R
chmod 750 /home/backup/.ssh/
echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDNoBYvmqNw6lU7XzpS25dzO9D3H0+Ou1OqW94i1FYEUe6nFJfKnSxCPsxXgwBvT7xZMx1EWW8A8kxrSiiEcaiGiI9PXvL7Kr6CFr+WmDqudDpcx7SVV2+n7ifaXjpxySKMKnGh/uCLR5P4ElLp0n5qRpG2lkEbXsRwqsnr4csnovmw5P8ZCEghAYK51hMBrTVsj6rKnjNVtQWPLPryPn6koDLcPZnGF9gaN5Azm42p7QLTE9bfzow4ZfGm5+ljiqiCINjGfkEyoEmNciyEmd8aVtcfcFAFxC3nwZXZ2KJgGag1tsPZNp5sqLmuSJKzxgM8tqyzU8XFLH3ClINWdd7R backup@abed.abcdef.lan" > /home/backup/.ssh/authorized_keys
sed -i 's/backup.*/backup:x:34:34:backup:\/home\/backup:\/bin\/sh/' /etc/passwd
cat > /etc/cron.daily/backup << EOL #!/bin/sh rm -f /home/backup/backup-* date="$(date +%Y-%m-%d_%H%M)" tar czf /home/backup/backup-\$date.tar.gz /config/ &> /dev/null
chmod 700 /home/backup/backup-\$date.tar.gz
chown backup:backup /home/backup/backup-\$date.tar.gz

chmod 775 /etc/cron.daily/backup
run-parts --verbose /etc/cron.daily

Enable SSH access on the box accessible from FreeNAS. To generate a key SSH as root into your FreeNAS and do su – backup to identify as backup user; then generate a ssh-key with ssh-keygen -t rsa. You can view your ssh-key with cat ~/.ssh/ Copy that in the script.

EdgeOS needs rsync

Don’t forget to install rsync on Ubiquiti EdgeOS devices

set system package repository wheezy components 'main contrib non-free'
set system package repository wheezy distribution wheezy
set system package repository wheezy url
sudo su -
apt-get update
apt-get install rsync

Configure FreeNAS

It’s best to test SSH connectivity towards each target on the command-line before attempting to configure an Rsync Task. You can do so by SSH’ing into your FreeNAS as root. Test the target by SSHing as backup user: su – backup, ssh target-ip, you should be logged-in without a hitch (accept the host-key if asked).

FreeBSD 11: configure OVH fail-over IP

2017/01/15 freebsd, network, OVH ,

This is my take at the FreeBSD 11 network configuration on fail-over IPs. Append the following to /etc/rc.conf. In my example em0 is the network interface (use ifconfig to confirm), is the VMs IP-address and is the ESXi host.

ifconfig_em0="inet netmask broadcast" 
routes_em_iface="-net -iface em0" 

We configure DNS resolving using the OVH DNS server by creating /etc/nslookup.conf with the following contents:


If you lose connectivity after a while check your dmesg for ARP entries changes mac-address (especially your ESXi host/gateway). If this happens you can create /etc/rc.local with:

arp -s 00:07:b4:00:01:02

It might not be the most OS-native way, if you have improvements please let me know.

µpdate: OSPF multipath routing on equal metrics

2014/07/04 edgeos, pfsense, µpdate ,

So, I was wondering why I frequently got disconnected from IRC and it turns out OSPF starts acting like multipath routing when you feed it two equal cost paths. To show and prove what’s happening.


µpdate: asymmetric routing with VRRP and OSPF

2014/07/02 edgeos, vyatta, µpdate , ,

I was playing with my network today when I noticed an interesting side-effect of my current network architecture. Simply put there are two layers of routers; the first do intranet routing, the second layer takes care of everything else (ie. the internets). The image depicts my beautifully inspiring wallpaper on Windows 7 where we call for louise. I printed the the default gateway and it looks like we’re taking 1.65 towards shirley first. 1.65 is actually a VRRP address and 1.67 does the actual lifting as confirmed in the tracert below. From there we egress out of 0.33 and meet up with louise, ‘sup. louise stubborn as she is decides to take 0.34 home, jeff answers the call of duty, but couldn’t care less about the whole ordeal and sends them over 0.66 towards me.


VRRP: IP high-availability (CARP/HSRP)

2014/05/06 debian, network, vyatta , , ,

Je hebt een netwerk met twee routers met beide toegang tot het internet. Je clients krijgen typisch maar één default route toegekend via DHCP, ze gebruiken dus maar één van de twee routers.
Vereiste voorkennis voor maximaal genot: basis netwerken.


Bovenstaande situatie kan je op meerdere manieren oplossen maar met VRRP wordt er een virtueel IP adres gedeeld door de routers. Het virtuele IP adres wordt doorgegeven zoals een estafette stokje en wordt ook altijd beantwoord door dezelfde machine zolang de situatie niet veranderd. De routers houden elkaar in de gaten om te zien of het tijd is om actie te ondernemen en zichzelf te promoveren tot nieuwe eigenaar van het virtuele adres.

ESXi: Virtualized Vyatta network performance

2013/07/25 virtualisation, vyatta ,

A small report on two different versions of Vyatta (6.3 and 6.5r1) with (outdated) but official VMware tools perform using iperf with default settings. We changed the MTU the second time and achieved our 10Gb/sec.