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
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.
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.
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—
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.
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.
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.
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.
BGP as an SDN? Clearly this must be some sort of mistake! Or maybe not. Consider, for a moment, the following network:
In the last post on SDNs, I spent a little time discussing just a bare minimum of some internal router architecture—specifically the difference between the RIB and the FIB, and thinking a little about management. In this post, I want to add one more dividing point to the mix, and then start thinking about how we can classify various “software defined” solutions in a way that makes more sense out of the field of options.