Russ
Author Archives: Russ
- Home → Author's archive:
Russ
Hedge 225: The CCNA
The CCNA has a long history as an important certification for network engineers. While the CCST has been created by Cisco “below” the CCNA, or as a different starting point, many network engineers begin their career with the CCNA. Join Jason Gooley, Wendell Odom, Tom, and Russ as we discuss the most recent updates to the CCNA, the way updates to the program are changing, and Jason’s and Wendell’s updated book on the CCNA.
Hedge 224: Is Open Source a Market Failure?
Is Open Source Software (OSS) a market failure? What does OSS add to the market that cannot be accomplished in other ways? What happened to the F (Free)? Join us for this roundtable episode of the Hedge.
History of Networking: Updated Links
Someone told me some (or many?) of the links are broken to the History of Networking recordings. I went through the S3 bucket and renamed all the files so there are no spaces (because S3 buckets don’t always work right with spaces), and then checked them all to make certain they work. Along the way I found three or four episodes that were recorded and not on the HoN page, so I added them.
Check out the corrected listing here.
I think I have one more recording that was never edited and published; I will probably put it in the Hedge stream in the next month or two just so it’s out there.
Hedge 223: The Political Side of Standards with Geoff Huston
Listen in as Geoff Huston, Tom, and Russ discuss how the IETF, governments, and political movements interact when creating standards and guiding the future of the Internet.
Hedge 222: Get out there and publish!
Eric Chou joins Tom and Russ to talk about the importance of creating content, and the many tools and ideas you can use to get out there and publish. You’ve heard us talk about this a lot–now it’s time to get out there and publish.
New Course: Coding Skills for Network Engineers
This Friday, Marlon Bailey and I will be teaching a new four-hour class on coding skills for network engineers over on Safari Books Online through Pearson. From the course description:
Network engineers are increasingly expected to know how to perform basic coding, like building scripts to gather information and build or maintain an automation system. In larger organizations with full-time coders, network engineers are expected to effectively work with coders, on their own turf, to build and maintain network automation systems. All of these tasks require a basic knowledge of the structure and terminology of programming. There are a lot of courses that show you how to build your first program, or how to perform basic tasks using common programming languages—this course is different. This course will help you build a “mental map” of the software development space, gathering ideas and patterns learned across years into a simple-to-understand format. In this course you will learn data structures, program flow control, and—most importantly—how to structure software for efficiency and maintainability over the long haul.
For anyone who doesn’t know Marlon, you can find his LinkedIn profile here.
Architecture and Process
Driving through some rural areas east of where I live, I noticed a lot of collections of buildings strung together being used as homes. The process seems to start when someone takes a travel trailer, places it on blocks (a foundation of sorts) and builds a spacious deck just outside the door. Over time, the deck is covered, then screened, then walled, becoming a room.
Once the deck becomes a room, a new deck is built, and the process begins anew. At some point, the occupants decide they need a place to store some sort of equipment, so they build a shed. Later, the shed is connected to the deck, the whole thing becomes an extension of the living space, and a new shed is built.
These … interesting … places to live are homes to the people who live in them. They are often, I assume, even happy homes.
But they are not houses in the proper sense of the word. There is no unifying theme, no thought of how traffic should flow and how people should live. They are a lot like the paths crisscrossing a campus—built where the grass died.
Our networks are like these homes—they are Continue reading
Hedge 221: Energy Aware Protocols
A lot of people are spending time thinking about how to make transport and control plane protocols more energy efficient. Is this effort worth it? What amount of power are we really like to save, and what downside potential is there in changing protocols to save energy? George Michaelson joins us from Australia to discuss energy awareness in protocols.
Hedge 220: The Cost of the Cloud
Cloud services are all the rage right now, but are they worth it? There are many aspects to the question, and the answer is almost always going to be “it depends.” Do you really need to spin up capacity more quickly than you can buy hardware and get it running? Do you really need to be able to spin capacity down without leaving any hardware behind? Is cloud really the best use of your team’s time and talent?
David Heinemeier Hansson joins Tom and Russ to talk about the economics and uses of cloud, and why his company has moved away from public cloud services.
Hedge 219: Are We There Yet?
We’ve been talking about many of the same things in networking since the late 1980s–autonomous, self-driving, autonomic, etc.–and yet … those things all still seem like some sort of Jetson’s cartoon episode. Why aren’t we there yet? Are these even the right goals?
On the ‘net: Networking Models
I’m writing a series on network models over at Packet Pushers; links to the first three are below.
Hedge 218: Longer than /24’s
Most providers will only accept a /24 or shorter IPv4 route because routers have always had limited amounts of forwarding table space. In fact, many hardware and software IPv4 forwarding implementations are optimized for a /24 or shorter prefix length. Justin Wilson joins Tom Ammon and Russ White to discuss why the DFZ might need to be expanded to longer prefix lengths, and the tradeoffs involved in doing so.
AI Assistants
I have written elsewhere about the danger of AI assistants leading to mediocrity. Humans tend to rely on authority figures rather strongly (see Obedience to Authority by Stanley Milgram as one example), and we often treat “the computer” as an authority figure.
The problem is, of course, Large Language Models—and AI of all kinds—are mostly pattern-matching machines or Chinese Rooms. A pattern-matching machine can be pretty effective at many interesting things, but it will always be, in essence, a summary of “what a lot of people think.” If you choose the right people to summarize, you might get close to the truth. Finding the right people to summarize, however, is beyond the powers of a pattern-matching machine.
Just because many “experts” say the same thing does not mean the thing is true, valid, or useful.
AI assistants can make people more productive, at least in terms of sheer output. Someone using an AI assistant will write more words per minute than someone who is not. Someone using an AI assistant will write more code daily than someone who is not.
But is it just more, or is it better?
Measuring the mediocratic effect of using AI systems, even as Continue reading
Hedge 217: Doug Madory and BGP Security Incidents
We hear a lot about BGP security incidents–but what is really going on? How often do these happen, and how much damage do they do? Doug Madory, who monitors these things for Kentik, joins Russ White and Tom Ammon to talk about BGP security in the wild.