In my last article, I discussed hyperconvergence at the network edge—the concept of composable systems and a scalable set of compute, storage, and network access resources. As the networking market often follows the compute and storage market in a broad sense, it would seem some thought around what hyperconvergence in the network itself might look like. What were the components of the hyperconverged system at the edge?
Part 1 - The Composable System
A revolution is taking place at the network edge. In the early days, rack mount computers were purchased in various sizes, mounted, and dedicated to a particular application. Over time, virtualization took hold, as well as the idea of separating storage from the processor and memory with it, leading to a disaggregated solution. Storage was often connected through the network as a Storage Area Network (SAN) or Network Attached Storage (NAS), providing pooled, high efficiency storage for large scale applications. The trend, in recent years, has been towards converged systems, which primarily means moving the storage back into the box, as a device locally attached to the processor’s bus.
DDoS is a Threat to Large and Small Operators Alike
Most large scale providers manage Distributed Denial of Service (DDoS) attacks by spreading the attack over as many servers as possible, and simply “eating” the traffic. This traffic spreading routine is normally accomplished using Border Gateway Protocol (BGP) communities and selective advertisement of reachable destinations, combined with the use of anycast to regionalize and manage load sharing on inbound network paths. But what about the smaller operator, who may only have two or three entry points, and does not have a large number of servers, or a large aggregate edge bandwidth, to react to DDoS attacks?
Topics: Cyber Security
Open Source Routers?
In the old westerns (often actually shot in Italy or Mexico, rather than the Western United States), when a new gunfighter strolls into town there will always be that fateful moment when someone will say, “this town ain’t big enough for the two of us.” Then some arrangement will be made to meet at dawn on the main street. In the routing world, the problem is often not too many gunfighters, but too few, particularly when it comes to routing stacks. There are a few, of course, including Cisco, Juniper, IP Infusion, Ericsson, and some other well-known names.
The Latest in the SDN Series
So far in this series on Software Defined Networks (SDNs), I’ve discussed a basic taxonomy that can be used to classify SDNs, some of the challenges with actually building a control plane, and examined several SDN and SDN-like solutions through the lens of the southbound interface. In order to help you understand the problem space better, this post will consider the CAP theorem in relation to the concept of an SDN.
Part of the SDN Series by Russ White
The original Path Computation Element Protocol (PCEP) work dates from the early 2000’s, with the first IETF RFC (4655) being made informational in 2006—which means PCEP predates the time when SDNs were “cool.” PCEP was originally, because of the increasingly complex nature of computing Traffic Engineering (TE) paths through (primarily), Service Provider (SP) networks. Three specific developments drove the design, standardization, and deployment of PCEP:
An SDN Blog by Russ White
The last post on the topic of interface to the routing system (I2RS) discussed use cases; this one will provide an overview of the I2RS architecture, and then consider some challenges in the neighborhood of I2RS. The architecture of I2RS is considered in the illustration below.
An SDN Blog by Russ White
Through this (probably far too long) series on SDNs, we have looked at BGP, Fibbing, and Openflow. BGP and Fibbing would be described as augmented control planes; the distributed control plane is not replaced, but rather augmented with a controller that modifies the best path decisions of the control plane by interacting with the control itself in a somewhat “native” way.
An SDN Blog by Russ White
Openflow is the “father of software defined networks” in the minds of many engineers. To understand Openflow, however, you cannot just look at the protocol itself; rather you must go back to the beginning, in the mists of old networking.
Another SDN Blog by Russ White
The last post on the topic of SDNs discussed BGP as a southbound interface to control policy. This form of SDN was once common in hyperscale data centers (though not as common as it once was). In our pursuit of out of the way (and hence interestingly different) forms of SDNs (hopefully this series will help you understand the scope and meaning of the concept of SDNs by examining both common and uncommon cases), it’s time to look at another unusual form of policy injection—Fibbing. In fibbing, a centralized controller engineers traffic flow in a link state network by interacting with the control plane directly, rather than interacting with the forwarding plane or the RIB.