Author Archives: Russ
Author Archives: Russ
The post Worth Reading: Independence from L2 data centers appeared first on 'net work.
Distributed Denial of Service attacks can damage your business—and they can be difficult to manage or counter. While there are a number of tools available to counter DDoS attacks, particularly in the commercial space, and there are a number of widely available DDoS protection services, sometimes it’s useful to know how to counter a DDoS on your own. One option is to absorb attacks across a broader set of inbound nodes. Let’s use the network below to illustrate (though often the scale needs to be quite a bit larger for this solution to be useful in the real world).
Assume, for the moment, that the attacker is injecting a DDoS stream from the black hat, sitting just behind AS65004. There are customers located in AS65001, 2, 3, 4, and 5. For whatever reason, the majority of the attacker’s traffic is coming in to site C, through AS65003. Normally this is a result of an anycast based service (such as active-active data centers, or a web based service, or a DNS service), combined with roughly geographical traffic patterns. Even a DDoS attack from a mid sized or large’ish botnet, or reflection off a set of DNS servers, can end up being Continue reading
The post Worth Reading: Converged systems hype appeared first on 'net work.
The post Worth Reading: What’s the deal with online journalism? appeared first on 'net work.
It was going to be a long evening, anyway—the flight check bird was coming in, and both Instrument Landing Systems (ILSs) needed to be tuned up and ready for the test. So we took some downtime, split into two teams, and worked our way through each piece of equipment—Localizer, Glide Slope, each marker in turn, VOR, TACAN—to make certain each was, as far as we could measure, sending the right signals to the right places. If flight check found even the smallest variance off what the ILS systems were supposed to be providing, they could shut the airfield down “until further notice.”
The team I was on was driving across one of the many roads out on the airfield, trying to catch up with the other half of the shop to find out what they had done, and what needed to be done. Off in the distance, we noted someone standing in the middle of a field between the roads, waving vigorously. We changed direction, driving across the bumpy field, through grass as high as the top of the hood (Base Ops was planning a burn, so they’d left the grass to grow a bit higher than normal). As Continue reading
Johnny Britt has started blogging over at route-spf.net (I guess he’s just going to write about link state… ). He’s just put his first post up, linked below. This one is worth watching for good material.
The post New Blog: Route-SPF appeared first on 'net work.
The post Worth Reading: The great 21st century data rush appeared first on 'net work.
The post Worth Reading: Little bits of security appeared first on 'net work.
Now that you have a copy of BGP in Go on your machine—it’s tempting to jump right in to asking the code questions, but it’s important to get a sense of how things are structured. In essence, you need to build a mental map of how the functionality of the protocol you already know is related to specific files and structure, so you can start in the right place when finding out how things work. Interacting with an implementation from the initial stages of process bringup, building data structures, and the like isn’t all that profitable. Rather, asking questions of the code is an iterative/interactive process.
Take what you know, form an impression of where you might look to find the answer to a particular question, and, in the process of finding the answer, learn more about the protocol, which will help you find answers more quickly in the future.
So let’s poke around the directory structure a little, think about how BGP works, and think about what might be where. To begin, what might we call the basic functions of BGP? Let me take a shot at a list (if you see things you think should be on here, Continue reading
So you’ve decided you want to be a network engineer—or you’re already you a network engineer, and you want to be a better engineer, to rise to the top, to be among the best, to… Well, you get the idea. The question is, how do you get from where you are now to where you want to be? This short volume is designed to answer just that question. If you’re expecting a book on technology, then you’re in the wrong place. Instead, this is a book about how to build a career in networking technology, including topics such engineering culture, being intentional about your education, thinking skills, and some basic skills you’ll want to develop.
The post So you want to be a better network engineer? … appeared first on 'net work.
The post Worth Reading: Live streaming to 800,000 users appeared first on 'net work.
The post Worth Reading: Alchemy can’t save Moore’s Law appeared first on 'net work.
The post Worth Reading: Open season appeared first on 'net work.
The post Worth Reading: Independence from L2 data centers appeared first on 'net work.
The post Worth Reading: Fishing for a cure to DDoS attacks appeared first on 'net work.
The post Worth Reading: APNIC’s cyber threat intellegence appeared first on 'net work.
I really dislike corporate VPNs that don’t allow split tunneling—disconnecting from the VPN to print on a local printer, or access a local network attached drive, puts a real crimp in productivity. In the case of services reachable over both IPv6 and IPv4, particularly if the IPv6 path is preferred, split tunneling can be quite dangerous, as explained in RFC7359. Let’s use the network below to illustrate.
In this network, host A is communicating with server B through a VPN, terminated by the VPN concentrator marked as “VPN.” Assume the host is reachable on both 192.0.2.1 and 2001:fb8:0:1::1. The host, the upstream router, the network in the cloud, and the server are all IPv6 reachable. When the host first connects, it will attempt both the IPv6 and IPv4 connections, and choose to use the IPv6 connection (this is what most current operating systems will do).
The problem is: the VPN connection doesn’t support IPv6 at all—it only supports IPv4. Because IPv6 is preferred, the traffic between the host and the server will take the local IPv6 connection, which is not encrypted—the blue dash/dot line—rather than the encrypted IPv4 tunnel—the red dashed line. The user, host, and Continue reading