Announcing NetBox

Wednesday, June 15, 2016 at 1:16 p.m. UTC by stretch

Several years ago, I lamented the few options available for a provider-grade IPAM solution. Specifically, I explained why building a custom application would be undesirable:

Could I create a custom IPAM solution with everything we need? Sure! The problem is that I'm a network engineer, not a programmer (a natural division of labor which, it seems, is mostly to blame for the lack of robust IPAM solutions available). Even if I had the time to undertake such a project, I have little interest in providing long-term maintenance of it.

But I suppose time makes fools of us all.

Nearly one year ago, I started developing an IPAM application as part of my day job. Leveraging my experience with the Django Python framework, I had a working proof-of-concept in just a week. Over the next several months, the project grew more mature and began to take on additional roles: data center infrastructure management, circuit tracking, and credentials storage. Today, the tool functions as our "source of truth" for many aspects of our infrastructure. We call it NetBox.

Continue reading 20 comments

Don't be Discouraged by Plagiarists

Wednesday, March 9, 2016 at 3:28 a.m. UTC by stretch

Recently, a friend pointed out that an individual had taken one of my cheat sheets, superimposed his own logo and URL on it, and published it as his own work. This is certainly not the first time I've been plagiarized, nor will it be the last, I suspect. I called out the individual on Twitter, and I'm very gratefully for the many people who helped me compel him to remove the illegitimate content. Eventually.

I wanted to write a quick post sharing my thoughts on this incident for the benefit of everyone who has expressed interest in starting their own blog or web site. I've heard plenty of people comment over the years to the effect of, "Why bother starting a blog if someone's just going to harvest the RSS feed and re-publish it on their own site to make a few bucks?" Indeed, this has always been a concern among producers of both free and paid content.

I wish I could tell you that plagiarism isn't that big a deal, or that it won't happen to you. But the truth is plagiarism is a huge problem in our industry (and across the Internet in general), and if you produce public content you will inevitably have to deal with it.

Continue reading 20 comments

Can You Keep a Secret? (Part 2)

Thursday, February 11, 2016 at 2:36 a.m. UTC by stretch

In part one, we saw how AES can be used to encrypt sensitive data so that it can be retrieved only by using an encryption key. The problem with this approach is that everyone who needs access to the data must have a copy of the key. If any one of these copies becomes compromised, the entire database must be re-encrypted using a new key, and the new key must be distributed securely to all parties involved. In this article, we'll see how symmetric encryption can be combined with asymmetric cryptography (namely RSA) to create a hybrid cryptosystem.

Let's begin by encrypting some data using AES as we did in part one. First we pad our plaintext's length to a multiple of 16 using null bytes, then generate a 256-bit encryption key and a 128-bit IV, and finally encrypt it with CFB-mode AES to generate a string of ciphertext.

>>> from Crypto.Cipher import AES
>>> import os
>>> plaintext = "Operation Neptune will launch on June 6th"
>>> plaintext += (16 - len(plaintext) % 16) * chr(0)
>>> encryption_key = os.urandom(32)
>>> iv = os.urandom(16)
>>> cipher = AES.new(encryption_key, AES.MODE_CFB, iv)
>>> ciphertext = cipher.encrypt(plaintext)
Continue reading 2 comments

Can You Keep a Secret?

Sunday, February 7, 2016 at 7:44 p.m. UTC by stretch

I've been developing an IPAM/DCIM tool for work over the past several months (more on that soon), and recently my focus has been on expanding it to store confidential data associated with network devices. Backup login credentials, TACACS+/RADIUS secrets, SNMP communities, and so on: Short strings that need to be stored securely.

Hashing

Storing a password or other small piece of sensitive data is different from merely authenticating against it. Most password storage mechanisms never actually store a user's actual password, but rather an irreversible hash of it. (That is if you're doing it correctly, at least.)

For example, the Django Python framework (which powers packetlife.net) by default employs salted SHA256 hashes to authenticate user passwords. When a password is saved, a random salt is generated and concatenated with the plaintext password. (A salt is used to prevent two identical passwords from producing the same hash.) The SHA256 algorithm is then run against the whole thing to produce a fixed-length hash. Here's an example in Python using Django's built-in make_password() function:

>>> from django.contrib.auth.hashers import make_password
>>> make_password("MyP@ssw0rd!")
u'pbkdf2_sha256$12000$x5E0yB2dh13m$ablUOER8qn4CxjmHZlJrUUA1Cb9MeLXvfggTnG56QpM='
Continue reading 3 comments

Stretch's Hierarchy of Network Needs

Monday, December 14, 2015 at 3:07 a.m. UTC by stretch

Remember Maslow's hierarchy of needs from school? The theory asserts that every human shares the same set of basic physical and psychological needs in order to be happy, with more primal needs like food and shelter taking precedence over emotional needs like love and companionship.

maslows_hierarchy.png

A while back, I was pondering what would be necessary to fully automate a network, and it occurred to me that a very similar hierarchy of needs can be laid out for a computer network to achieve its optimal state.

1. A Functioning Network

At the very bottom of the hierarchy is everything a network requires to function: Routers, switches, cabling, power, and so on, just as tier one of Maslow's hierarchy encompasses everything a human needs to stay alive. At this stage, a network can function, and can even function well, but it cannot adapt or grow.

Many small businesses operate their networks at this stage for years with no major problems. After all, when left alone, computers and networks tend to just keep chugging along. And if your entire network comprises a cable modem, a switch, and a few access points, it's entirely possible that it will run for years without needing any tweaking.

Continue reading 7 comments

Thoughts on Two Years of Working from Home

Wednesday, November 11, 2015 at 3:44 a.m. UTC by stretch

I've spent the past two years working from home as a network engineer for two different companies. At first, I wasn't sure how well the remote lifestyle would suit me, but after a short time I settled into a very comfortable routine. And to my surprise, I discovered that I was much more productive working from the serenity of my home office than I ever was in a cubicle. I'd like to share my observations with the hope of convincing others to try ditching the office as well.

Why Work Remote?

No More Commute

This is the most obvious benefit to working remote. No more sitting in rush hour traffic twice a day. Even if you take public transit and are able to play on your laptop for most of the trip, commuting is a major time sink. Most people will instantly gain back at least an hour of time by foregoing the daily drive to and from the office. What could you do with an extra hour each day?

And beyond time, there are ample corollary benefits. You (or your company) are no longer paying for as much fuel or fare. You're greatly reducing your risk of being injured in a traffic accident, simply by reducing exposure. You're reducing your carbon footprint. And you're one less car on the road or occupied seat on the train, which reduces the burden on public infrastructure that's already strained to the breaking point in many cities.

Continue reading 32 comments

Writing a Custom IPAM Application

Monday, August 10, 2015 at 1:14 a.m. UTC by stretch

Four years ago, I lamented the lackluster selection of IPAM applications available for service providers. Unfortunately, it seems not much has changed lately. I was back to exploring IPAM offerings again recently, this time with the needs of a cloud hosting provider in mind. I demoed a few tools, but none of them seemed to fit the bill (or they did, but were laughably overpriced).

So, I decided to write my own. In my rantings a few years back, I had considered this option:

Could I create a custom IPAM solution with everything we need? Sure! The problem is that I'm a network engineer, not a programmer (a natural division of labor which, it seems, is mostly to blame for the lack of robust IPAM solutions available). Even if I had the time to undertake such a project, I have little interest in providing long-term maintenance of it.

My opinion has not changed, but I've come to realize that if I want a tool that fits my requirements, I will need to build it. And after surprisingly little time, I'm happy to report that I have now have a kick-ass IPAM tool that does exactly what I want it to.

While I can't share the code, which is owned by and purpose-built for my employer, I would like to share some tips I picked up in the process with the hope of convincing others that rolling your own tools really isn't that hard. And in many cases, it may be well worth the effort.

Continue reading 11 comments

What the CCIE does not Prove

Friday, May 29, 2015 at 2:27 p.m. UTC by stretch

I came across an article today about a 19-year-old who earned his CCIE. It reminded me of a Reddit post from a few weeks ago. Someone asked why, when evaluating a CCIE, hiring managers still demand a number of years of practical experience in the field.

I'm in a situation where I'm a CCNP with 3 years of experience. I want to get my CCIE but I keep being told left and right I don't have enough experience and I'll never get a CCIE job without 7 years of experience. Am I supposed to just laze around and wait until I get more experience? It just doesn't make sense.

This is a fairly common misunderstanding among people new to our field, and is largely the result of vendor marketing. People want so badly to believe that a certification proves their worth as an individual, when in reality its value is much more narrowly defined.

Continue reading 44 comments

Traceroute and Not-so-Equal ECMP

Monday, April 27, 2015 at 2:05 p.m. UTC by stretch

I came across an odd little issue recently involving equal-cost multipath (ECMP) routing and traceroute. Traceroutes from within our network to destinations out on the Internet were following two different paths, with one path being one hop longer than the other. This resulted in mangled traceroute output, impeding our ability to troubleshoot.

The relevant network topology comprises a mesh of two edge routers and two core switches. Each edge router has a number of transit circuits to different providers, and advertises a default route via OSPF to the two core switches below. The core switches each load-balance traffic across both default routes to either edge routers.

topology.png

Because each edge router has different providers, some destinations are routed out via edge1 and others via edge2, which means sometimes a packet will be routed to edge2 via edge1, or vice versa.

two_paths.png

Routers typically employ a hash function using layer three and four information from each packet to pseudo-randomly distribute traffic across equal links. Typically, all packets belonging to a flow (e.g. all packets with the same source and destination IP and port numbers) follow the same path.

However, in this case traceroute packets were being split across two path of unequal length, which made traceroute output pretty much unreadable. We noticed that only UDP traceroutes were affected; ICMP traceroutes reported one path as normal.

Continue reading 12 comments


About Packet Life

PacketLife.net is the work of a network engineer named Jeremy Stretch. It began as a repository for Cisco certification study notes in 2008, but quickly grew into a popular community web site.

The site's goal is to offer free, quality technical education to networkers all over the world, regardless of skill level or background.

Blog Spotlight

New RFCs

IETF