I was setting up an internal enablement session on how to demo vCenter Operations for View and came across the usual SE problem of trying to simulate in a lab environment something broken in a very simple real world way. You’d think it would be easy to simulate broken things but coming up with something repeatable, real world and low touch (we don’t want to have to spend hours unpicking something after a demo) is often a problem.
For vCenter Operations for View (V4V) I thought introducing some latency and packet loss would make a good troubleshooting demo. But how do we do that?
My first thought was to VPN into our Palo Alto network and ‘hairpin’ back to the lab. Unfortunately that proved difficult to achieve and I quickly got bored of entering RSA codes to try and get it working.
A quick google and I discovered courtesy of Joe Miller that Mac OS includes dummynet and I can quickly create a script to introduce the necessary latency and packet loss. A few teaks as the suggested values would totally kill a View session (I want to show degradation, not a dead system!) and I now have two files I can use – hilatency.sh to start the demo and lolatency.sh to turn it off.
hilatency.sh to turn it on
#!/bin/bash sudo ipfw add pipe 1 ip from any to 80.xxx.yyy.zzz sudo ipfw add pipe 2 ip from 80.xxx.yyy.xxx to any sudo ipfw pipe 1 config delay 100ms bw 1Mbit/s plr 0.01 sudo ipfw pipe 2 config delay 100ms bw 1Mbit/s plr 0.01 sudo sysctl -w net.inet.ip.fw.enable=1
lolatency.sh to turn it off
sudo ipfw -q flush
To run them just fire up Teminal and run the scripts:
. hilatency.sh . lolatency.sh
Job done! And this is how it looks in V4V…
PICTURE TO BE ADDED
CloudyTechnologist 