For some time now Gigabit has been the de-facto speed for networking equipment. The days of vendors getting away with selling Gigabit at premium is mostly gone. The only real exception to that seems to be Cisco, who inside on providing Fast Ethernet (100Mb) ports on many of their devices and charging a premium for Gigabit.
Ten Gigabit is becoming more widely available in enterprise environments, but comes at a cost that is out of reach of many home labs and those on a tight budget. Depending on what you need to achieve there are low-cost options for getting your feet wet with 10Gb or faster.
Those on a tight budget are likely to consider LACP to aggregate multiple GbE connections in order to provide more available bandwidth. Unfortunately this isn’t always suitable, especially so if you need a single connection to consume much of the bandwidth. Thankfully assuming you only need to connect two hosts together there is a better way.
Continue reading Faster than Gigabit on a budget
The IOS DHCP server can be configured to provide different address information to clients based on information they provide via DHCP option 60.
DHCP Option 60 is the “vendor class identifier option” that allows the DHCP client to identify its type so that custom configuration can be applied.
Configuring the DHCP Client
For custom address configuration to be applied the client must specify option 60. This is configured with the “ip dhcp client class-id XXX” command, where XXX is an ASCII label to use. For example:
description ** Corporate LAN - Management Address **
ip dhcp client class-id CUSTOM_CLASS
ip address dhcp
Configuring the DHCP Server
To configure the IOS DHCP server you must specify a default class and then a class that will match against DHCP option 60. When matching against option 60 you must convert the ASCII string the client sends (e.g. “CUSTOM_CLASS”) to hexadecimal.
ip dhcp class DEFAULT
remark IP addresses for devices not providing a class-id
ip dhcp class CUSTOM_CLASS
remark IP addresses for devices providing "CUSTOM_CLASS"
option 60 hex 435553544f4d5f434c415353
With the matching setup the DHCP pool configuration can be split into the custom class and a default:
ip dhcp pool LAN
network 192.168.0.0 255.255.255.0
address range 192.168.0.210 192.168.0.220
address range 192.168.0.0 192.168.0.200
If this doesn’t work the following debug commands may be helpful in identifying the cause of the problem:
debug ip dhcp server class
debug ip dhcp server packet detail
If you’ve thin-provisioned a VMDK under ESXi and need to reduce it for whatever reason, the official VMware documentation suggest to migrate the VM to another datastore using VMware converter which is not always practical, thankfully an alternative exists.
If you have enabled Change Block Tracking (CBT) be sure to disable it by adjusting the ctkEnabled option on the virtual machine and consolidating disks before you begin.
To reclaim space you need to fill all unallocated space with zeros. On Windows you can use SDelete or the following command on Linux:
cat /dev/zero > zero.dat;sync;sleep 1;sync;rm -f zero.dat
Once the space has been filled with zeros you can shrink the partition as required. I usually use GParted for this. With your partitions shrunk the next step is to reclaim the space, shut-down the VM and SSH into your ESXi host. “CD” to the directory containing the VM and identify the file you need to shrink for example:
# cd /vmfs/volumes/SXi01-local/SRVGEN02
/vmfs/volumes/53930418-064abd7c-45c9-002590dbfde4/SRVGEN02 # ls -lsah
8 drwxr-xr-x 1 root root 2.6K Feb 21 11:01 .
1024 drwxr-xr-t 1 root root 2.6K Jan 15 13:27 ..
8192 -rw------- 1 root root 7.5M Feb 21 11:00 SRVGEN02-000001-ctk.vmdk
1024 -rw------- 1 root root 244.0K Feb 21 11:00 SRVGEN02-000001-delta.vmdk
0 -rw------- 1 root root 387 Feb 21 11:00 SRVGEN02-000001.vmdk
8192 -rw------- 1 root root 7.5M Feb 21 10:59 SRVGEN02-ctk.vmdk
119531520 -rw------- 1 root root 120.0G Feb 21 10:59 SRVGEN02-flat.vmdk
1024 -rw------- 1 root root 8.5K Feb 21 10:59 SRVGEN02.nvram
0 -rw------- 1 root root 589 Feb 21 10:59 SRVGEN02.vmdk
0 -rw-r--r-- 1 root root 77 Feb 21 11:01 SRVGEN02.vmsd
8 -rwxr-xr-x 1 root root 3.0K Feb 21 11:00 SRVGEN02.vmx
0 -rw-r--r-- 1 root root 263 Jan 17 13:55 SRVGEN02.vmxf
1024 -rw-r--r-- 1 root root 353.9K Feb 21 10:52 vmware-10.log
1024 -rw-r--r-- 1 root root 182.9K Feb 21 10:59 vmware-11.log
1024 -rw-r--r-- 1 root root 182.2K Feb 19 18:53 vmware-6.log
1024 -rw-r--r-- 1 root root 182.3K Feb 19 19:01 vmware-7.log
1024 -rw-r--r-- 1 root root 182.3K Feb 19 19:10 vmware-8.log
1024 -rw-r--r-- 1 root root 183.2K Feb 21 10:46 vmware-9.log
1024 -rw-r--r-- 1 root root 104.2K Feb 21 10:59 vmware.log
Next, run “vmkfstools –punchzero DISK_NAME.vmdk” to actually shrink the file. How long this takes will depend on the underlying storage, on a reasonably fast SSD this took less than ten minutes for me to shrink 110GB:
/vmfs/volumes/53930418-064abd7c-45c9-002590dbfde4/SRVGEN02 # vmkfstools --punchzero SRVGEN02.vmdk
vmfsDisk: 1, rdmDisk: 0, blockSize: 1048576
Hole Punching: 100% done.