Faster than Gigabit on a budget

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

Configure Cisco IOS DHCP to use vendor class IDs

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:

interface Vlan10
  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
    address range
  class DEFAULT
    address range

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

Shrink a thin-provisioned VMDK

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
total 119558160
     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.