Soon…

I have been working on a new project, so the blog was a little delayed. I have tons of trouble shooting cases/tickets to share with you, so stay tuned. I’ll publish the next Ticket on Monday.

Data Storage: The Foundation & potential Achilles Heel of Cloud Computing

In almost anything that you read about Cloud Computing, the statement that it is ‘nothing new’ is usually made at some point. The statement then goes on to qualify Cloud Computing as a cumulative epiphenomenon that more so serves as a single label to a multi-faceted substrate of component technologies than it does to a single new technology paradigm. All of them used together comprise the constitution of what could be defined as a cloud. As the previous statement makes apparent the definition is somewhat nebulous. Additionally, I could provide a long list of the component technologies within the substrate that could ‘potentially’ be involved. Instead, I will filter out the majority and focus on a subset of technologies that could be considered ‘key’ components to making cloud services work.

If we were to try to identify the most important component out of this substrate, most would agree that it is something known as virtualization. In the cloud, virtualization occurs at several levels. It can range from ‘what does what’ (server & application virtualization) to ‘what goes where’ (data storage virtualization) to ‘who is where’ (mobility and virtual networking). When viewed as such, one could even come to the conclusion Continue reading

The Silicon Choice for Cloud Networking

These days there is much discussion whether switches or routers should be built with proprietary custom ASICs or standard “merchant silicon” chips. At one level, the question is “Why does it matter?” After all, networking vendors have been building custom silicon chips since the invention of the LAN switch in the early ’90s.

In my own career, I have led the development of several generations of very high volume network switch silicon. However, even I could not design better silicon switch chips than what is available now on the merchant market. To me this is an inflection point for the industry that is not unlike what happened in the computer industry with the adoption of industry standard architectures.

While CPU and switch silicon architectures differ in many ways, the underlying economics are very similar. In the 1980s and 1990s, CPU architectures flourished: there were MIPS, PowerPC, SPARC, ARM, and X86. Each architecture staked out their position in the market. The RISC architectures led the server market with 64-bit addressing and multi-processing capability, and also focussed on embedded applications. X86 was the standard for desktop computers. However as the years passed, most of the volume growth in the market has Continue reading

Moving to ZFS

My file server is full and I have no options for expanding it. The server is a white box system running FreeBSD with a hardware RAID card and 400GB of RAID-5 storage. The hardware is old, the hard drives are old and I can't expand it. It's time for something new.

OpenBSD Compact Flash Firewall

The goals of this project was to build a low-power, small form factor machine that runs OpenBSD and acts as a firewall/router in a home network or small business setting. This page walks through the hardware I chose and the process I use to get OpenBSD running on the CF card. Table of Contents Hardware Operating System System Operation Hardware The design has gone through two generations of hardware now.

OpenBSD IPsec Tunnel Guide

This guide will explain how to setup a site-to-site IPsec tunnel (i.e., tunnel mode IPsec) between two OpenBSD gateways. Throughout this document there are example configs shown, some of which contain secret key data. DO NOT use these example keys! Create your own (as shown) and keep them private. Table of Contents Introduction The Tools Terminology Building a Site-to-Site Tunnel Starting isakmpd Allowing IPsec Traffic Through pf(4) Filtering Traffic on the Tunnel Adding Redundancy Troubleshooting The Tools OpenBSD ships with all the tools needed to begin using IPsec.

Installing Olive 7.1

Olive refers to a regular PC that's running Juniper Networks’ JUNOS software. Juniper developed Olive early on so they could perform testing of JUNOS during development. These days Olive is deprecated in favor of cheap, low-end M and J-series routers.

OpenBSD CARP Notes

CARP is the Common Address Redundancy Protocol. It's a secure, free alternative to the Virtual Router Redundancy Protocol and the Hot Standby Router Protocol. CARP was created and is maintained by the OpenBSD project. The notes here apply to OpenBSD 5.0 and higher. Protocol Information Virtual MAC Address The virtual MAC is in the format 00-00-5e-00-01-XX where the last octet is filled in by the CARP vhid. IP Protocol CARP uses IP protocol number 112 (0x70).

OpenBSD OpenBGPD Notes

OpenBGPD is a free, open-source implementation of the Border Gateway Protocol Version 4. It was created and is maintained by the OpenBSD project. The notes here apply to OpenBGPD as found in OpenBSD 4.0 and higher. Path Selection Process OpenBGPD will only ever install one route in the route table for a particular destination network (prefix). If OpenBGPD receives information about that prefix from more than one peer, a decision must be made on which one to use.

OpenBSD SNMP MIBs

The following SNMP MIBs and the accompanying code that extend the Net-SNMP daemon allow administrators to query information from various OpenBSD subsystems. Currently, stats can be queried from: Packet Filter The kernel sensors framework Common Address Redundancy Protocol (CARP) These MIBs are being integrated into OpenBSD's own snmpd. OpenBSD 5.1 has the kernel sensor and CARP MIBs. OpenBSD 5.1-current has and the future 5.2 release will have the pf MIB.

NetPacket PERL Module Enhancements

NetPacket provides a base class for a cluster of modules related to decoding and encoding of network protocol packets. Each NetPacket descendant module knows how to encode and decode packets for the network protocol it implements. Protocols that NetPacket can encode/decode include IPv4, TCP, UDP, ICMP, Ethernet, and ARP. I've written three additional modules for NetPacket that allow the encoding/decoding of IPv6, ICMPv6, and OpenBSD's Packet Filter binary log files. I've also made numerous changes to existing modules, including fixing spelling mistakes, bug fixes, and documentation enhancements.

Monitoring Postfix

The goal here is to monitor servers running Postfix to determine the number of email messages delivered locally and abroad and to graph that data. The data will be made available via Net-SNMP for collection using your NMS of choice. Postfix homepage: http://www.postfix.org/ Basis for this Work The methods outlined below are based on the work of Craig Sanders http://taz.net.au/postfix/mrtg/. Some things that are done different here: Only one database file is used for storing the data instead of two.

Monitoring BIND9

The goal here is to monitor DNS servers running BIND version 9 and graph the various statistics that it records about itself. The statistics will be made available to the Net-SNMP daemon by a script. From there, the data can be polled by whatever NMS you choose to use. Table of Contents Getting Stats from BIND Serving Stats via SNMP Download for BIND 9.4 Download for BIND 9.6 and Newer Notes
1 3,692 3,693 3,694