Russ

Author Archives: Russ

History of Networking: Paul Vixie on the Origins of DNS

Paul Vixie joins us on the History of Networking to talk about the spread of the DNS system—like a virus through the body network. All those radios in the background at a bit of history; Paul is an Amateur Radio Operator of many years, though, like me, he is not as active as he used to be in this realm.

Some Market Thoughts on the Broadcom SDKLT

Broadcom, to much fanfare, has announced a new open source API that can be used to program and manage their Tomahawk set of chips. As a general refresher, the Tomahawk chip series is the small buffer, moderate forwarding table size hardware network switching platform on which a wide array of 1RU (and some chassis) routers (often called switches, but this is just a bad habit of the networking world) used in large scale data centers. In fact, I cannot think of a single large scale data center operating today that does not somehow involve some version of the Tomahawk chip set.

What does this all mean? While I will probably end up running a number of posts on SDKLT over time, I want to start with just some general observations about the meaning of this move on the part of Broadcom for the overall network engineering world.

This is a strong validation of a bifurcation in the market between disaggregation and hyperconvergence in the networking world. Back when the CCDE was designed and developed, there was a strong sense among the folks working on the certification that design and operations were splitting. This trend is still ongoing, probably ultimately resulting Continue reading

Live Training at Safari Books: How the Internet Really Works

I will be teaching my first live training course at Safari Books Online on the 9th of March, starting at noon ET: How the Internet Really Works. It’s hard to describe the level and background for this training, as it will be all over the place; this is a bit of an experiment in this realm. The course description is—

This live training will provide an overview of the systems, providers, and standards bodies important to the operation of the global Internet, including the Domain Name System (DNS), the routing and transport systems, standards bodies, and registrars. For DNS, the process of a query will be considered in some detail, who pays for each server used in the resolution process, and tools engineers can use to interact DNS. For routing and transport, the role of each kind of provider will be considered, along with how they make money to cover their costs, and how engineers can interact with the global routing table (the Default Free Zone, of DFZ). Finally, registrars and standards bodies will be considered, including their organizational structure, how they generate revenue, and how to find their standards.

You can find more information here.

Rehashing Certifications

While at Cisco Live in Barcelona this week, I had a chat with someone—I don’t remember who—about certifications. The main point that came out of the conversation was this:

One of the big dangers with chasing a certification is you will end up chasing knowledge about using a particular vendor feature set, rather than chasing knowledge about a technology.

At some point I’m going to edit a post a video short on engineering versus meta-engineering (no, it won’t be next week), but the danger is real. For instance, in an article I’ve had in my bookmarks pile for a long while, the author says—

My boss advised me that getting my WPCE (WordPerfect Certified Resource) cert would accomplish two things: 1. It would establish my credibility as a trainer; and 2. If I didn’t know a feature before the test, I sure as heck would afterward.

I’m not going to name the author, because this is his description of thinking through a certification many years ago, rather than his current thinking on certifications—but the example is telling. I know a lot of folks studying for certifications. They mostly spend their time labbing up various protocols and… features. The temptation to Continue reading

Giving the Monkey a Smaller Club

Over at the ACM blog, there is a terrific article about software design that has direct application to network design and architecture.

The problem is that once you give a monkey a club, he is going to hit you with it if you try to take it away from him.

What do monkeys and clubs have to do with software or network design? The primary point of interaction is security. The club you intend to make your network operator’s life easier is also a club an attacker can use to break into your network, or damage its operation. Clubs are just that way. If you think of the collection of tools as not just tools, but also as an attack surface, you can immediately see the correlation between the available tools and the attack surface. One way to increase security is to reduce the attack surface, and one way to reduce the attack surface is tools, reduce the number of tools—or the club.

The best way to reduce the attack surface of a piece of software is to remove any unnecessary code.

Consider this: the components of any network are actually made up of code. So to translate this to Continue reading

Learning to Ask Questions

A lot of folks ask me about learning theory—they don’t have the time for it, or they don’t understand why they should. This video is in answer to that question.

1 66 67 68 69 70 162