0

Network Toolkit

My case full of network doodads always generates lots of questions when people see it for the first time. I don't carry dedicated iPhone chargers anymore, but Apple cube chargers forgotten behind hotel nightstands is where this started.

With this kit it is immediately apparent when something is missing, so things tend to not get left behind.

The limited space has driven me to find the best and most compact solutions to all of my problems. I'm really pleased with everything that's in here. I'm also aware that it's super nerdy.


The case itself is a Duluu Essential case for iPad. It's a nice semi-rigid clamshell type case. I've made two modifications:

1. Removed the padded "page" between the two halves. This thing was intended to keep the stuff in the pockets on the left from scratching the iPad on the right. It also served as an iPad stand.
2. I removed the original zipper pulls, replaced them with a repair part because the square corners of the original pulls tended to cause problems.

0

When CDP doesn’t discover

Marko's myths of VLAN 1 post continues to drive a lot of traffic to my response about CDP, tagging and the magic properties of VLAN 1.

Today I was introduced to a related phenomenon that I found interesting.

Backstory
CDP messages sent by switches are always in VLAN 1. If something other than VLAN 1 is the native VLAN on a particular trunk, then the CDP frame will be tagged with "1".

Funny Business
According to the post linked above there are related conditions that break CDP altogether.

The required elements are:

1. A switch sending tagged CDP frames, either because it's using something other than VLAN 1 as the native VLAN or it's been configured with vlan dot1q tag native
2. A router-on-a-stick that does NOT have a subinterface configured with encapsulation dot1q 1

0

Dealing with Corrupt Opegear Firmware

It was inevitable. Now that I'm proudly compiling my own cellular router firmware, I'm also becoming familiar with the process of recovering from corrupt firmware.

I'm using an Ubuntu VM (described in the previous post) running in my MacBook for recovery purposes.

The Opengear instructions for recovering from bad firmware suggest that holding down the reset button is required, but I find that my router attempts to load firmware from the network no matter what. Maybe that's because I've wiped out my configuration? <- Update: yes, this seems to be the case. I haven't nailed it down exactly, but my router doesn't try to netboot every time.

Here's how I'm using that Ubuntu VM:

Required Packages
sudo apt-get install -y tftpd-hpa dhcp3-server

0

Compiling Firmware for Opengear ACM5000

Opengear gave me two ACM5000 units as a part of my attendance at Network Field Day 4 in October of last year. The gift has not influenced my opinion of the company nor their product: I continue to think they're a bunch of amazingly clever people, and that they make the best out-of-band access equipment on the market. I recommend them without hesitation nor reservation.

I've been waiting anxiously for the release of the Custom Development Kit (CDK) based on release 3.6 code, and it's finally out. The README that comes with the CDK is a bit dated, and not super easy to follow, so I'm sharing my notes on rolling custom firmware here.

I started with Ubuntu 12.04.2 Server i386 installed inside VMware Fusion on my MacBook. I pretty much took the defaults, allowing VMware to manage the install for me (how cool is this feature?)

Remote Access
Pretty soon I was looking at an Ubuntu login prompt in the VMware console, I logged in and then did:

sudo apt-get -y update
sudo apt-get -y upgrade
sudo apt-get -y install openssh-server
ifconfig eth0

Now I could log in via SSH, so I was done Continue reading

0

Rambling on about IP fragmentation

Fragmentation! Squarely on-topic for this blog, I guess.

An issue on a customer's network had me thinking about IP fragmentation recently, and now I find myself pounding some things that I find interesting about fragmentation into my keyboard.

Where should an oversized datagram be sliced?
RFC791 suggests a scheme by which an IP datagram is sliced up so that the resulting fragments just fit out the constraining interface. This seems sensible, but there are some gotchas:

• If we fragment a 1500 byte packet to fit into a PPPoE link, we might wind up with 1492 bytes in the first datagram (20 bytes header, 1472 bytes payload) and 28 bytes in the second packet (20 bytes header, 8 bytes payload). This works great until that first fragment tries to transit a GRE tunnel (MTU 1476) further along its path. If the PPPoE router had chopped the datagram in half, both fragments would fit through the GRE tunnel without any problem.
• Depending on the MTU, we might not be able to make precisely MTU-sized fragments. This is because the fragment offset value in the IP header is expressed in terms of 8-byte chunks. Every IP fragment must have an offset that's a multiple Continue reading

0

What did West Virginia officials buy exactly?

The state of West Virginia has landed in the headlines a couple of times recently due to their purchase of wildly inappropriate Cisco routers for over 1000 locations around the state. There have been no shortage of commenters laying the blame at Cisco's feet, but the auditor's report disagrees. It's back in the headlines now because of the recent release of the report, and because of Cisco's pledge to buy the gear back and help the state buy more appropriate equipment.

The auditor's report is an interesting read. Here are some of the highlights from my reading of it:

3945 routers were selected because of two key requirements communicated by the state:

• Dual internal power supplies, which narrows the selection to 3925 and 3945 models
• Use of two service module slots on day one, and a desire to have the option to grow beyond these two at some point in the future.

Unfortunately, these two requirements seem to have been communicated in a meeting, because no emails were available to corroborate them, but members of the team who purchased the gear acknowledge that the requirement did originate with the state. So, that's how they wound up in a 3945 chassis.

Continue reading

0

Offline Cable Management

Full disclosure: I got some stuff for free. Details.

In The Old Days
Cisco Catalysts used to be offered with RJ21 (Amphenol) connectors, rather than individual 8P8C jacks. Installations using this type of switch always stayed nice and clean regardless of the port density because the inevitable tangled mess of cable developed in a different rack, far away from failed fan trays, line cards, power supplies, etc...

I'm not sure why, but Cisco stopped offering line cards with RJ21 interfaces. It doesn't seem like this needed to happen: 1000BASE-T requires the same type of cable (Category 5) as 100BASE-TX, and Cisco demonstrated that the port density required for 48 gigabit ports is possible.

I worked in one environment where the tradition of remote patching continued on gigabit gear through the use of 25-pair cables terminated with six individual 8P8C connectors. Whenever a new switch or line card got installed, it was immediately populated with eight of these multi-headed copper cables. They terminated in a very large 110 block patch area. It worked well, but the Plug Pack is better.

Six Pack Rings For Network Cables
Panduit's Plug Pack modules keep your cables nicely collated, especially when a component is removed Continue reading

0

Quick-n-dirty ‘network’ statement generator

I recently had a requirement to feed a lab router a bunch of BGP prefixes for some testing. The test required a non-overlapping, random-looking population of prefixes from several different eBGP neighbors.

I decided to bang together a little script to generate the prefixes in a format suitable for quagga's bgpd daemon, but wound up adding features throughout the day as I discovered new requirements. The end result was something that might be useful to somebody else.

Here I'm telling it to give me 5 network statements from within 10.0.0.0/8. The netmask will be 24 bits:

$ ./bgpdgen.pl -c 5 -n 10.0.0.0/8 -m 24
 network 10.160.244.0/24
 network 10.61.69.0/24
 network 10.13.1.0/24
 network 10.13.138.0/24
 network 10.50.109.0/24

$ ./bgpdgen.pl -c 5 -n 10.0.0.0/24 -m 26-30
 network 10.0.0.224/28
 network 10.0.0.112/28
 network 10.0.0.0/26
 network 10.0.0.80/28
 network 10.0.0.24/29

0

Native VLAN – Some Surprising Results

I did some fiddling around with router-on-a-stick configurations recently and found some native VLAN behavior that took me by surprise.

Dead Simple Routers-On-A-Stick Configuration

0

New 10Gb/s Interconnect Options

Followers of this blog, or folks who've heard me on the Packet Pushers Podcast may have noticed that I obsessively look for less expensive ways to interconnect data center devices.

That's because the modules are so expensive! A loaded Nexus 7010 is intimidating enough with it's $473,000 list price, but that's without any optic modules...

If we want to link those interfaces to something with 10GBASE SR modules then triple the budget because the optics cost twice as much as the switch: