Author Archive

wwt (Wiimms WBFS Tool) Usage Examples

Friday, October 14th, 2011

It took me a bit of trial and error to get this tool to do exactly what I wanted, so here are a few quick examples that hopefully will save you some time.

Updating the WBFS partition

Copy everything in the /source/path directory to the wbfs partition (auto detected) that doesn’t already exist on the wbfs partition.

# sudo wwt UPDATE -t /source/path/ --auto


UPDATE: Copy only new files
-t: Test mode, don't make any changes (until this flag is removed)
--auto: Auto detect the wbfs drive destination

What Could Have Saved Dropbox?

Tuesday, June 21st, 2011

Update Aug 2012: dropbox has implemented multi-factor auth! Read more…

Well, the cat is out of the bag. Dropbox has announced that they accidentally introduced (and then quickly remediated) a bug that had disabled authentication. This left the front door wide open to all of their 25+ million accounts for a few hours. Certainly a big mistake, but this makes me wonder. Is this the sort of thing that could only happen to Dropbox? I mean development happens at breakneck speed these days. With the common mindset of “release early and release often” a bug making its way into production is not surprising to me at all.

This got me thinking. Could this whole thing have been avoided? If development moves at a pace which makes it difficult to QA every detail, perhaps redundancy is the answer. What if, instead of relying solely on a username and password, additional factors were verified when users attempt to authenticate? Had this been the case, things could have played out much differently for Dropbox.

Thinking Outside the Password:

IP addresses If a user is trying to log in from an IP address that isn’t recognized, require them to verify their secret phrase, or to verify via e-mail, etc.

Cookies Similar to the IP address, if a user hasn’t logged in before from their current computer, browser, app, whatever, have them jump through hoops to verify their identity.

External Authentication Services There are many sites out there pushing their own auth services. Openid, google, and facebook, to name a few. Why not link the local account to one of these services to implement multi-factor auth, requiring both valid local and external credentials before permitting entrance.

Text Message When users register accounts, have them enter a mobile phone number. Then when they authenticate, text them a random number and require them to type it in.

Strange Behavior If you see a user trying to log in simultaneously from many different places make them, verify their account. If you see a single IP trying to reach into many different user accounts, block the IP and require those accounts to be verified. Etc.

All in all, I think this temporary security hole could have been avoided. Not by expecting developers to never make mistakes, but instead by embracing human error as a fact of life and implementing a layered authentication and security methodology.

Freeing Disk Space in Linux

Tuesday, June 14th, 2011

Did you know that most filesystems reserve a percentage of the available free space as an emergency reserve for when the disk becomes full? This is a great safety mechanism if you’re running critical applications or database, but in many cases all this reserved space winds up going to waste. Especially so in the case of today’s 2 & 3 Terabyte disks!

On a linux EXT filesystem, 5% is reserved for access only by the root user. Assuming you have a 2T disk this is approximately 100G reservation, which is total overkill if you ask me! Luckily it’s easy enough to adjust on-the-fly with the tune2fs command.

For this example I’m going to change the number of reserved blocks from the default of 5% to 1% on the filesystem mounted as /misc.

A simple df -h will show you free space minus the reserve.

[root@foo ~]# df -h | grep misc
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda5             789G  110G  639G  15% /misc

As you can see, there is 639G of free space on this filesystem.

Now, we use tune2fs -m 1 to change the percentage reserved to 1%

[root@foo ~]# tune2fs -m 1 /dev/sda5
tune2fs 1.39 (29-May-2006)
Setting reserved blocks percentage to 1% (2133291 blocks)

Now we check the available space

[root@foo ~]# df -h | grep misc
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda5             789G  110G  672G  14% /misc

Now we have 672G free. That’s 33G of storage we just got back for free!

Now, it may seem attractive to set this to 0% to squeeze the most possible free space from your drive, and under some circumstances this is perfectly safe to do. However, don’t set this to 0% if you have processes running as root that you want to continue running if the disk fills. Here’s a simple of thumb if you’re not sure. If you’ll loose irreplaceable data (or your job) if this filesystem goes casters up, don’t set to 0%.

Converting Windows Guests From VMWare ESX to KVM With Virtio Drivers

Friday, June 10th, 2011

The below steps were tested while pulling my hair out trying to migrate a Windows 2k3 guest from VMWare ESX to KVM managed by libvirt, hopefully this will save you from much windows related pain and suffering.

Prep the VM while it’s still running in VMware

Download MergeIDE.zip and run MergeIDE.bat. This is a really important step that will prepare the system to boot using an IDE driver when we bring it up in KVM. Skipping this step will likely result in blue screen errors and much frustration.

MergeIDE can be downloaded at
http://www.virtualbox.org/attachment/wiki/Migrate_Windows/MergeIDE.zip

Also, ensure that you know the local administrator password. This seems rather obvious but networking may not come up, so best to be prepared.

Now you’re ready to shut down and copy the vm.

Shutdown the VM and copy it’s vmdk

Gracefully shut down the VM. Once it’s down, ssh into your ESX server and navigate to the appropriate VMFS volume containing your VM.

[root@esx1 example-vm]# pwd
/vmfs/volumes/VMFS1/example-vm
[root@esx1 example-vm]# ls
example-vm-flat.vmdk    example-vm.vmdk  example-vm.vmx   
example-vm.nvram      example-vm.vmsd  example-vm.vmxf 
vmware-0.log  vmware-2.log  vmware-7.log  vmware.log
vmware-1.log  vmware-6.log  vmware-8.log

SCP the “flat” .vmdk file (or files if your machine has multiple virtual disks) from your ESX host to your KVM host.

[root@esx1 example-vm]# scp -pr example-vm-flat.vmdk kvm1:/etc/libvirt/images/
root@kvm1 password: 
example-vm-flat.vmdk           100%   20GB  14.6MB/s   23:20

Prepare the libvirt/KVM instance

Create an XML file to define the attributes of the virtual machine. You’ll likely want to copy things like the memory size, number of CPUs and MAC address from the vmware vmx file, in our case this is /vmfs/volumes/VMFS1/example-vm/example-vm.vmx.

In order to set up virtio we first set our primry disk as bus type ide and create a secondary disk with a bus type of virtio. This will allow us to boot from the existing OS without special drivers. From there windows will detect the secondary virtio SCSI adapter and prompt for driver installation. We’ll also attach a virtio guest drivers floppy while we’re at it.

Virtio guest driver iso and floppy images can be downloaded at
http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/

<domain type='kvm'>
  <name>example-vm</name>
  <uuid>5de881b6-7738-4c30-8f14-da203c1b09f5</uuid>
  <memory>2097152</memory>
  <currentMemory>2097152</currentMemory>
  <vcpu>1</vcpu>
  <os>
    <type arch='x86_64' machine='rhel5.4.0'>hvm</type>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
  </features>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <emulator>/usr/libexec/qemu-kvm</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' cache='none'/>
      <source file='/etc/libvirt/images/example-vm/example-vm-flat.vmdk'/>
      <target dev='hda' bus='ide'/>
      <driver name='qemu' cache='none'/>
      <source file='/etc/libvirt/images/example-vm/virtio-temp.raw'/>
      <target dev='vdb' bus='virtio'/>
    </disk>
    <disk type='file' device='floppy'>
      <source file='/root/virtio-win-1.1.16.vfd'/>
      <target dev='fda' bus='fdc'/>
    </disk>
      <readonly/>
    </disk>
    <interface type='bridge'>
      <mac address='00:50:56:b9:4e:50'/>
      <source bridge='virbr0'/>
      <model type='virtio'/>
    </interface>
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target port='0'/>
    </console>
    <input type='mouse' bus='ps2'/>
    <graphics type='vnc' port='-1' autoport='yes' keymap='en-us'/>
  </devices>
</domain>

Note: if you need to generate a new uuid simply run uuidgen

Now you’re ready to “Define” the new virtual machine in libvirt.

[root@kvm1 ~]# virsh define /etc/libvirt/qemu/example-vm.xml 
Domain example-vm defined from /etc/libvirt/qemu/example-vm.xml

Boot the KVM guest

Using virt-manager, start the virtual machine. It should boot up and allow you to log in as a local administrator or with cached credentials. If you are seeing a bsod (blue screen) with error 0x000007b boot errors, verify that the MergeIDE step was successful. This resolved my 0x7b errors.

Install the windows virtio guest drivers

Upon logging in, windows should detect the new virtio SCSI and network hardware and prompt you for drivers. You’ll want to point it at the floppy drive we attached to the guest.

A very detailed description of what to do is available at
http://www.linux-kvm.org/page/WindowsGuestDrivers/viostor/installation#Non-System_disk_installation_procedure.

Change the primary disk from ide to virtio

Finally, once the virtio drivers have been successfully installed you’re ready to change your boot disk to a bus type of virtio and can remove the temporary second drive. This can be done by executing virsh edit example-vm while the host is running and changing the disk dev= and bus= as follows:

    <disk type='file' device='disk'>
      <driver name='qemu' cache='none'/>
      <source file='/etc/libvirt/images/example-vm/example-vm-flat.vmdk'/>
      <target dev='vda' bus='virtio'/>
    </disk>

You can also remove the driver floppy at this time.

Perform a full reboot of the guest

To make the above change take effect simply shut the machine down completely and then re-start it with virt-manager. Don’t simply issue a reboot from within the VM, we need to apply the changes to the libvirt domain definition.

You’re done!

Your VM should now be up and running, free from vmware and benefiting from the performance gains of virtio.

Mounting a File System on a Partition Inside of an LVM Volume

Thursday, May 12th, 2011

In my linux virtual environment I am using LVM volumes as the backing devices for virtual machines. Each of these LVM volumes contains a partition table splitting the LVM volume into at least one linux partition and one swap partition. In order to access these partitions from the dom0 host itself we can use the kpartx command to create device mapper entries which correspond to each of the partitions.

In this example we want to access the ext3 filesystem contained on the first partition of the “vm_example” logical volume.

 
[root@vm ~]# lvs
  LV              VG   Attr   LSize  Origin Snap%  Move Log Copy%  Convert
  vm_example      vg0  -wi-ao  6.00G                                      
 
[root@vm ~]# fdisk -l /dev/vg0/vm_example 
 
Disk /dev/vg0/vm_example: 6442 MB, 6442450944 bytes
255 heads, 63 sectors/track, 783 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
 
              Device Boot      Start         End      Blocks   Id  System
/dev/vg0/vm_example1               1         653     5245191   83  Linux
/dev/vg0/vm_example2             654         783     1044225   82  Linux swap / Solaris

As you can see, partition 1 is type linux and partition 2 is type linux swap. Now we use kpartx with the -a flag to create the device mapper entries for the partitions displayed above.

[root@vm ~]# kpartx -a /dev/vg0/vm_example

And now we can interact with the /dev/mapper devices as you normally would to mount, fsck, etc.

 
[root@vm ~]# file -s /dev/mapper/vm_example1 
/dev/mapper/vm_example1: Linux rev 1.0 ext3 filesystem data (large files)
 
[root@vm ~]# file -s /dev/mapper/vm_example2
/dev/mapper/vm_example2: Linux/i386 swap file (new style) 1 (4K pages) size 261055 pages

Then, when you’re finished, clean up with the kpartx -d command. The logical volume will remain in-use until this is done.

[root@vm ~]# kpartx -d /dev/vg0/vm_example

Coping With Cloud Downtime

Thursday, April 21st, 2011

In light of the recent Amazon cloud service interruptions it seems like a good time to share some ideas about how to help keep cloud hosted services available during unexpected and potentially long lasting outages.

Each of these items can be implemented using free and open source software either hosted in your own datacenter or *gasp* in a different cloud.

Use Puppet instead of custom machine images.

Sure, custom machine images are useful for quickly lighting up lots of copies of the same system, but they fall down in many ways.

  • Applying/reverting changes to already running instances is a manual process.
  • No way to ensure that systems are in a consistent state.
  • Updating images is cumbersome, especially for minior config tweaks.
  • Machine instance versions are a pain to keep track of, and can sprawl out of control.
  • Dependency on specific cloud resources can make them difficult to access during an outage.
  • Small differences in system configs require a whole new machine image.

    A configuration management system like Puppet provides you ability to customize machine images, plus it avoids the above shortcomings and provides a number of extra features.

  • Automatic propagation of configuration changes to all relevent systems.
  • Regular checks are performed to ensure system consistency. If a difference is detected the necessary updates are made automatically.
  • Provides a single location and interface for system configuration.
  • Small differences between systems are easy to incorporate while using the same template.
  • Provides the ability to push a configuration change out to all systems right away.
  • There are no dependencies on a particular cloud technology.
  • Revision control is easy to hook in and lets you quickly revert changes that didn’t go quite as expected.
  • System configuration details are inherently documented in detail by the configuration manifests.

    Synchronize your data elsewere on a regular basis.

    Cloud storage offers some really compelling features and is very useful, don’t get me wrong. But I wouldn’t expect it to always be there. Especially if the backups and snapshots that you depend on for recovery are hosted with the same provider, running the same software, potentially inside the same physical facilities. After all, cloud storage is susceptible to the same problems as any other storage platform. It’s a good idea to keep backups outside the cloud (or at least inside a different cloud). The simpler the backup methodology, the better.

    Rsync, mylvmbackup, rsnapshot and rdiff-backup are great open source backup tools that are secure and are optimized for efficiency with bandwidth and on-disk size.

    Manage your systems from outside the cloud.

    If your infrastructre is a cloud and the running instances are aircraft, then configuration management and monitoring systems are ground control. If they were hosted in the same cloud as the systems they manage, game over.

    By separating your management infrastructure and your service delivery infrastructure you gain the ability to monitor and manage systems remotely. You can even quickly deploy replacement resources elsewhere using a config management system and then copy your most recent off-cloud backup up there to restore your database and web content.

    Optimize your DNS configuration.

    If things are looking really bad you can at least put up a maintenance page. That is if you can update your DNS and get the chages to propagate quickly. Ensuring the following ahead of time will save you many headaches in the event of a service outage.

  • Set your DNS TTL low. This makes your DNS updates take effect more quickly, reducing the number of error messages your users see.
  • Use as many DNS servers are you can get your hands on. Lots of DNS servers means that the chances of one or more of them having problems is less likely to affect you. After all, they may be using the same cloud resources that you are!

    Verify that you have a backup MX.

    While we’re on the subject of DNS, it’s a good idea to make sure you have a backup mail exchanger configured and defined as an MX for your domain. It doesn’t have to be anything fancy, just something to recieve and queue up mail until you’re able to get the primary mail system back online.

    Keep thinking and talking about it!

    The above ideas hopefully are a good starting point for protecting yourself against unexpected outages but it definitely doesn’t stop here.

    What practices have worked well for you or your company?

    What ideas do you have?

  • Ubuntu Lucid 10.04 Cobbler Kickstart Setup How To

    Thursday, February 17th, 2011

    Importing the ISO

    At the time of this writing the version of cobbler available for CentOS-5 via the EPEL repo was 2.0.3.1. This version doesn’t seem to include proper support for “breeds” other than redhat, allthough it is alluded to in the documentation. So, in order to import the ubuntu media, I had to perform a few extra manual steps.

    Copy the ISO contents to a directory that corresponds to the name of your distro

    In my case this is Ubunutu-10.04-x86_64. I created the directory /var/www/cobbler/ks_mirror/ and copied the entire contents of the mounted ubunutu lucid installer ISO to this location.

    To mount an iso file in linux the command is something like

    mount -o loop /path/to/lucid.iso /mnt/foo

    Creating the .treeinfo file manually

    Once the files have been copied, you should put a .treeinfo file in place too. Koan freaked out when this file wasn’t present when I attempted to perform a –virt install. I think this is safe to omit if you aren’t planning on using Koan.

    [general]
    family = Ubuntu
    timestamp = 1272326522.13
    totaldiscs = 1
    version = 10.04
    discnum = 1
    packagedir = dists
    arch = x86_64
     
    [images-x86_64]
    kernel = install/netboot/ubuntu-installer/amd64/linux
    initrd = install/netboot/ubuntu-installer/amd64/initrd.gz

    Creating the Distro

    Now, it’s time to create the cobbler distro manually. This is straightforward enough, just double check all your paths and names to make sure evertyhing matches up.

    Here’s what mine looks like:

    [root@cobbler cobbler]# cobbler distro report --name="Ubuntu-10.04-x86_64"
    Name                           : Ubuntu-10.04-x86_64
    Architecture                   : x86_64
    Breed                          : generic
    Comment                        : 
    Initrd                         : /var/www/cobbler/ks_mirror/Ubuntu-10.04-x86_64/install/netboot/ubuntu-installer/amd64/initrd.gz
    Kernel                         : /var/www/cobbler/ks_mirror/Ubuntu-10.04-x86_64/install/netboot/ubuntu-installer/amd64/linux
    Kernel Options                 : {}
    Kernel Options (Post Install)  : {}
    Kickstart Metadata             : {'tree': 'http://@@http_server@@/cblr/links/Ubuntu-10.04-x86_64'}
    Management Classes             : []
    OS Version                     : generic26
    Owners                         : ['admin']
    Red Hat Management Key         : <<inherit>>
    Red Hat Management Server      : <<inherit>>
    Template Files                 : {}

    In my case I specificed a Breed of “generic” and an OS Version of “generic26”. Here’s hoping that this gets sorted out formally and makes its way through the EPEL repo soon.

    Creating the Ubuntu 10.04 Lucid Kickstart Template

    Here’s an example kickstart that is working for automated installes of Ubunutu 10.04 Lucid. It’s not 100% dynamic, but it works well.

    #/var/lib/cobbler/kickstarts/lucid.ks
    #
     
    #System language
    lang en_US
     
    #Language modules to install
    langsupport en_US
     
    #System keyboard
    keyboard us
     
    #System mouse
    mouse
     
    #System timezone
    timezone America/New_York
     
    #Root password
    rootpw --iscrypted $default_password_crypted
     
    #Initial user
    user --disabled
     
    #Reboot after installation
    reboot
     
    #Use text mode install
    text
     
    #Install OS instead of upgrade
    install
     
    # Use network installation
    url --url=$tree
     
    #System bootloader configuration
    bootloader --location=mbr 
     
    #Clear the Master Boot Record
    zerombr yes
     
    #Partition clearing information
    clearpart --all --initlabel 
     
    #Disk partitioning information
    part swap --size 512
    part / --fstype ext3 --size 1 --grow 
     
    #System authorization infomation
    auth  --useshadow  --enablemd5
     
    #Network information
    network --bootproto=dhcp --device=eth0
     
    #Firewall configuration
    firewall --enabled --trust=eth0 --ssh 
     
    #Do not configure the X Window System
    skipx
     
    %pre
     
    #services
    services --enabled=ntpd,nscd,puppet
     
    #Package install information
    %packages
    ubuntu-standard
    man-db
    wget
    postfix
    openssh-server
    sysstat
    nfs-common
    nscd
    postfix
    quota
    ntp
    puppet
     
    %post
    #raw
    sed -i 's/no/yes/' /etc/default/puppet 
    #end raw

    Creating the Profile

    Creating the profile is much like creating the distro, matching up the vairables. I’ve also specified some extra kernel options to output the installer to the serial console (ttyS0) which I find preferable for –virt installs.

    [root@cobbler cobbler]# cobbler profile report --name="Ubuntu-10.04-x86_64"
    Name                           : Ubuntu-10.04-x86_64
    Comment                        : 
    DHCP Tag                       : default
    Distribution                   : Ubuntu-10.04-x86_64
    Enable PXE Menu?               : False
    Kernel Options                 : {'text': '~', 'console': ['tty0', 'ttyS0,9600n8'], 'nofb': '~'}
    Kernel Options (Post Install)  : {'console': ['tty0', 'ttyS0,9600n8'], 'nofb': '~'}
    Kickstart                      : /var/lib/cobbler/kickstarts/lucid.ks
    Kickstart Metadata             : {}
    Management Classes             : []
    Name Servers                   : []
    Name Servers Search Path       : []
    Owners                         : ['admin']
    Parent Profile                 : 
    Red Hat Management Key         : <<inherit>>
    Red Hat Management Server      : <<inherit>>
    Repos                          : ['ubuntu-lucid-x86_64']
    Server Override                : <<inherit>>
    Template Files                 : {}
    Virt Auto Boot                 : 0
    Virt Bridge                    : br345
    Virt CPUs                      : 1
    Virt File Size(GB)             : 5
    Virt Path                      : 
    Virt RAM (MB)                  : 512
    Virt Type                      : qemu

    Note: I manually created an apt-mirror named ubunutu-lucid-x86_64. You could use any other ubuntu repo you’d like, local or remote.

    Notes & Future Improvements

    This should get you going in the right direction towards automating your ubuntu builds with a cobbler install sourcesd from EPEL. Hopefully soon a fix for this will make its way into the EPEL repos.

    Finding a MAC Address in VMware ESX

    Wednesday, February 16th, 2011

    Sometimes you just have to trace a system down by its MAC address. It could be a security incident, an abuse complaint or perhaps a long forgotten legacy system. Whatever it is, you don’t have much info to work with, but you do have a hardware address. Sadly, VMware doesn’t seem to have an easy way to search for a host by its MAC address. And filtering by corresponding IP address in the VI client only works if your VMware tools are installed and working. Which, after all, probably isn’t the case if all you know about a machine is its MAC address. Luckily with root shell access to the ESX hosts you can force a MAC address search easily enough.

    The following one-liner will search the VMFSes presented to the host for a given string, for our purposes it’s a MAC address. In many cases running this search from one ESX node will effectively search the whole cluster, because they all share the same VMFS datastores.

    [root@esx1 root]$ find /vmfs/volumes | grep .vmx$ | while read i; do \
                      grep -i "00:50:56:b9:79:70" "$i" && echo "$i"; done
    ethernet0.generatedAddress = "00:50:56:b9:79:70"
    /vmfs/volumes/49358dcc-139b80f0-2d98-001ec9cf6a91/FOOVM/FOOVM.vmx

    What the above script does is grep for the mac address 00:50:56:b9:79:70 in all files ending with .vmx in /vmfs/volumes. If a match is found, the full path to that vmx file is printed to the screen and from there you can glean the name and location of this formerly elusive virtual machine.

    Xen Disk Hot Add (Block Device) Howto

    Tuesday, January 18th, 2011

    Xen allows you to hot add (and remove) disks to a guest domU while the system is running. To do this you’ll use the ‘xm block-*’ commands.

    Hot Add

    To hot add a disk we use the ‘xm block-attach’ command.

    Usage: xm block-attach <Domain> <BackDev> <FrontDev> <Mode> [BackDomain]

    Let me describe what each of these arguments means:

    Domain: The name of the guest domU you wish to add a block device to.
    BackDev: The location of the block device in the dom0
    FrontDev: The device name to assign the new device in the domU
    Mode: read-only or read-write (r or w)

    For example, we have a physical (phy:) LVM device called /dev/vg0/vm_osol that we want to attach to a virtual machine named ‘comlag’ as /dev/xvda3.

    xm block-attach comlag phy:/dev/vg0/vm_osol /dev/xvda3 w

    The device /dev/xvda3 will become available on comlag. Because we used mode “w” the device is presented as read/write and we can now mount, format, enable swap and do anything else you normally would do with a block device.

    Hot Remove

    To hot remove we use the ‘xm block-detach’ command.

    Usage: xm block-detach <Domain> <DevId> [-f|--force]

    Domain: Name of the guest domU
    DevId: Name of the device within the domU (same idea as FrontDev above)

    Now let’s remove the device we just attached to comlag.

    Note: Be sure that the device isn’t mounted, or you risk damaging the contents of the block device.

     xm block-detach comlag /dev/xvda3

    And that’s it. Just be sure to update your xen config files to reflect any change you make by hot-add or these changes will go away when the domain is re-created.

    CIDR Cheat Sheet – IP Subnet & Netmask info

    Monday, January 10th, 2011

    This cidr cheat sheet provides a quick lookup table for common subnet and netmask calculations/translations. Must have for sysadmins and network engineers. Print out a copy and pin it up in your office.

    CIDR Cheat Sheet

    CIDR Cheat Sheet
     
    Netmask              Netmask (binary)                 CIDR     Notes    
    _____________________________________________________________________________
    255.255.255.255  11111111.11111111.11111111.11111111  /32  Host (single addr)
    255.255.255.254  11111111.11111111.11111111.11111110  /31  Unuseable
    255.255.255.252  11111111.11111111.11111111.11111100  /30    2  useable
    255.255.255.248  11111111.11111111.11111111.11111000  /29    6  useable
    255.255.255.240  11111111.11111111.11111111.11110000  /28   14  useable
    255.255.255.224  11111111.11111111.11111111.11100000  /27   30  useable
    255.255.255.192  11111111.11111111.11111111.11000000  /26   62  useable
    255.255.255.128  11111111.11111111.11111111.10000000  /25  126  useable
    255.255.255.0    11111111.11111111.11111111.00000000  /24 "Class C" 254 useable
     
    255.255.254.0    11111111.11111111.11111110.00000000  /23    2  Class C's
    255.255.252.0    11111111.11111111.11111100.00000000  /22    4  Class C's
    255.255.248.0    11111111.11111111.11111000.00000000  /21    8  Class C's
    255.255.240.0    11111111.11111111.11110000.00000000  /20   16  Class C's
    255.255.224.0    11111111.11111111.11100000.00000000  /19   32  Class C's
    255.255.192.0    11111111.11111111.11000000.00000000  /18   64  Class C's
    255.255.128.0    11111111.11111111.10000000.00000000  /17  128  Class C's
    255.255.0.0      11111111.11111111.00000000.00000000  /16  "Class B"
     
    255.254.0.0      11111111.11111110.00000000.00000000  /15    2  Class B's
    255.252.0.0      11111111.11111100.00000000.00000000  /14    4  Class B's
    255.248.0.0      11111111.11111000.00000000.00000000  /13    8  Class B's
    255.240.0.0      11111111.11110000.00000000.00000000  /12   16  Class B's
    255.224.0.0      11111111.11100000.00000000.00000000  /11   32  Class B's
    255.192.0.0      11111111.11000000.00000000.00000000  /10   64  Class B's
    255.128.0.0      11111111.10000000.00000000.00000000  /9   128  Class B's
    255.0.0.0        11111111.00000000.00000000.00000000  /8   "Class A"
     
    254.0.0.0        11111110.00000000.00000000.00000000  /7
    252.0.0.0        11111100.00000000.00000000.00000000  /6
    248.0.0.0        11111000.00000000.00000000.00000000  /5
    240.0.0.0        11110000.00000000.00000000.00000000  /4
    224.0.0.0        11100000.00000000.00000000.00000000  /3
    192.0.0.0        11000000.00000000.00000000.00000000  /2
    128.0.0.0        10000000.00000000.00000000.00000000  /1
    0.0.0.0          00000000.00000000.00000000.00000000  /0   IP space
     
                                       Net     Host    Total
    Net      Addr                      Addr    Addr    Number
    Class   Range      NetMask         Bits    Bits   of hosts
    ----------------------------------------------------------
    A        0-127    255.0.0.0         8      24     16777216   (i.e. 114.0.0.0)
    B      128-191    255.255.0.0      16      16        65536   (i.e. 150.0.0.0)
    C      192-254    255.255.255.0    24       8          256   (i.e. 199.0.0.0)
    D      224-239    (multicast)
    E      240-255    (reserved)
    F      208-215    255.255.255.240  28       4           16
    G      216/8      ARIN - North America
    G      217/8      RIPE NCC - Europe
    G      218-219/8  APNIC
    H      220-221    255.255.255.248  29       3            8   (reserved)
    K      222-223    255.255.255.254  31       1            2   (reserved)
    (ref: RFC1375 & http://www.iana.org/assignments/ipv4-address-space )
    (               http://www.iana.org/numbers.htm                    )
    ----------------------------------------------------------
     
    The current list of special use prefixes:
    	0.0.0.0/8	
    	127.0.0.0/8
    	192.0.2.0/24
    	10.0.0.0/8
    	172.16.0.0/12
    	192.168.0.0/16
    	169.254.0.0/16
    	all D/E space
    (ref: RFC1918 http://www.rfc-editor.org/rfc/rfc1918.txt   )
    (       or     ftp://ftp.isi.edu/in-notes/rfc1918.txt     )
    (rfc search:   http://www.rfc-editor.org/rfcsearch.html   )
    (              http://www.ietf.org/ietf/1id-abstracts.txt )
    (              http://www.ietf.org/shadow.html            )
     
     
    Martians: (updates at: www.iana.org/assignments/ipv4-address-space )
     no ip source-route
     access-list 100 deny   ip host 0.0.0.0 any
      deny ip 0.0.0.0         0.255.255.255  any log  ! antispoof
      deny ip 0.0.0.0 0.255.255.255  0.0.0.0 255.255.255.255 ! antispoof
      deny ip any             255.255.255.128 0.0.0.127 ! antispoof
      deny ip host            0.0.0.0        any log  ! antispoof
      deny ip host            [router intf]  [router intf] ! antispoof
      deny ip xxx.xxx.xxx.0   0.0.0.255      any log  ! lan area
      deny ip 0/8             0.255.255.255  any log  ! IANA - Reserved
      deny ip 1/8             0.255.255.255  any log  ! IANA - Reserved
      deny ip 2/8             0.255.255.255  any log  ! IANA - Reserved
      deny ip 5/8             0.255.255.255  any log  ! IANA - Reserved
      deny ip 7/8             0.255.255.255  any log  ! IANA - Reserved
      deny ip 10.0.0.0        0.255.255.255  any log  ! IANA - Private Use
      deny ip 23/8            0.255.255.255  any log  ! IANA - Reserved
      deny ip 27/8            0.255.255.255  any log  ! IANA - Reserved
      deny ip 31/8            0.255.255.255  any log  ! IANA - Reserved
      deny ip 36-37/8         0.255.255.255  any log  ! IANA - Reserved
      deny ip 39/8            0.255.255.255  any log  ! IANA - Reserved
      deny ip 41-42/8         0.255.255.255  any log  ! IANA - Reserved
      deny ip 50/8            0.255.255.255  any log  ! IANA - Reserved
      deny ip 58-60/8         0.255.255.255  any log  ! IANA - Reserved
      deny ip 69-79/8         0.255.255.255  any log  ! IANA - Reserved
      deny ip 82-95/8         0.255.255.255  any log  ! IANA - Reserved
      deny ip 96-126/8        0.255.255.255  any log  ! IANA - Reserved
      deny ip 127/8           0.255.255.255  any log  ! IANA - Reserved
      deny ip 169.254.0.0     0.0.255.255    any log  ! link-local network
      deny ip 172.16.0.0      0.15.255.255   any log  ! reserved
      deny ip 192.168.0.0     0.0.255.255    any log  ! reserved
      deny ip 192.0.2.0       0.0.0.255      any log  ! test network
      deny ip 197/8           0.255.255.255  any log  ! IANA - Reserved
      deny ip 220/8           0.255.255.255  any log  ! IANA - Reserved
      deny ip 222-223/8       0.255.255.255  any log  ! IANA - Reserved
      deny ip 224.0.0.0       31.255.255.255 any log  ! multicast
      deny ip 224.0.0.0       15.255.255.255 any log  ! unless MBGP-learned routes
      deny ip 224-239/8       0.255.255.255  any log  ! IANA - Multicast
      deny ip 240-255/8       0.255.255.255  any log  ! IANA - Reserved
     
    filtered source addresses
      0/8                 ! broadcast
      10/8                ! RFC 1918 private
      127/8               ! loopback
      169.254.0/16        ! link local
      172.16.0.0/12       ! RFC 1918 private
      192.0.2.0/24        ! TEST-NET
      192.168.0/16        ! RFC 1918 private
      224.0.0.0/4         ! class D multicast
      240.0.0.0/5         ! class E reserved
      248.0.0.0/5         ! reserved
      255.255.255.255/32  ! broadcast
     
    ARIN administrated blocks: (http://www.arin.net/regserv/IPStats.html)
       24.0.0.0/8 (portions of)
       63.0.0.0/8
       64.0.0.0/8
       65.0.0.0/8
       66.0.0.0/8
      196.0.0.0/8
      198.0.0.0/8
      199.0.0.0/8
      200.0.0.0/8
      204.0.0.0/8
      205.0.0.0/8
      206.0.0.0/8
      207.0.0.0/8
      208.0.0.0/8
      209.0.0.0/8
      216.0.0.0/8

    A coworker linked me to this great cidr cheat sheet. I’m mirroring a copy of it here for future reference and availability. http://www.oav.net/mirrors/cidr.html