MESSAGE
| DATE | 2015-06-10 |
| FROM | Ruben Safir
|
| SUBJECT | Subject: [LIU Comp Sci] Dynamic Network Stacks
|
From owner-learn-outgoing-at-mrbrklyn.com Wed Jun 10 01:02:23 2015
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix)
id 6F8C51612EF; Wed, 10 Jun 2015 01:02:23 -0400 (EDT)
Delivered-To: learn-outgoing-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix, from userid 28)
id 491761612F3; Wed, 10 Jun 2015 01:02:23 -0400 (EDT)
Delivered-To: learn-at-nylxs.com
Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89])
by mrbrklyn.com (Postfix) with ESMTP id 6D8DB1612EF;
Wed, 10 Jun 2015 01:01:56 -0400 (EDT)
Received: from [10.0.0.19] (www.mrbrklyn.com [96.57.23.82])
by mailbackend.panix.com (Postfix) with ESMTPSA id 65B8A138FF;
Wed, 10 Jun 2015 01:01:56 -0400 (EDT)
Message-ID: <5577C4C4.8010209-at-panix.com>
Date: Wed, 10 Jun 2015 01:01:56 -0400
From: Ruben Safir
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Hangout , learn-at-nylxs.com
Subject: [LIU Comp Sci] Dynamic Network Stacks
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Sender: owner-learn-at-mrbrklyn.com
Precedence: bulk
Reply-To: learn-at-mrbrklyn.com
http://www.theregister.co.uk/2015/06/08/sdn_nfv_the_future_or_toast/
Data Centre
More like this
* Cisco
* Hewlett Packard
* Software Defined Networking
* Network Function Virtualisation
Software-defined freedom: A liberating experience for YOU
Breaking through the hardware barricades to a new network state
Protestor barricade image via Shutterstock
8 Jun 2015 at 10:29, Trevor Pott
Software Defined Networking (SDN) and Network Functions Virtualisation
(NFV) are the future – and if you aren't already learning about them
you're probably already doomed. If that strikes you as a little
pessimistic then there is a bright side: most of us are already doing
some of it and we all understand more about it than we think.
SDN is the ability to rapidly detect and adapt to changes in network
infrastructure. This can be, say, the addition of devices or changes in
topology.
NFV is the ability to stand up, tear down, automate and orchestrate
network elements in some easy-to-use manner. Network elements can
include switches, routers, firewalls, Intrusion Detection Systems (IDS),
monitoring, port mirroring and even entire clusters of virtual or
physical server instances.
NFV is frequently lumped in with SDN, as both technologies are highly
complimentary. It is possible to do NFV without SDN (see: /Webmin's
virtual twin/ here
).
It is also entirely possible to implement SDN without layering NFV over
the top.
None of this is new. The "wow" factor to SDN is that instead of having
to log into each switch or router one at a time (via scripts, GUI or
command line), your entire network is orchestrated by some centralised
management server.
Let's consider a few practical examples.
SDN networking gear
The most colour-by-numbers type of hype-compliant SDN today involves
switches that "separate the control plane from the data plane".
Translated into human, this means people are finally making centralised
management for switches so we don't have to log in via telnet or SSH to
every switch on our network.
In practice, SDN means buying inexpensive switches where the hardware
manufacturers don't make a lot of margin and installing expensive
software on it. This is quite a change from the old practice of
expensive hardware and terrible (or no) software.
The expensive software portion of the SDN equation allows switch
configurations to be monitored in real time. When an event occurs (maybe
a dead port, cable out, or switch down) the centralised control server
or servers detect the issue and automatically change relevant network
configurations to keep as many of the network services running as possible.
Consider for a moment a simple network with four switches. Each switch
has a connection to two other switches. Two of the switches connect to
the router that goes out to the internet. Cut any one connection between
the switches and they would still be able to see other switches.
Example of 4 switches for an SDN layout
Basic 4 switch setup with a failed link between switches 1 and 3
Sadly, it's never that simple.
Let's say that the cable between Switch 1 and Switch 3 occupies port 4
on both switches. Every time Switch 1 is asked to find devices that are
attached to Switch 3, it will fire those packets out of port 4, because
that's what Switch 1's map of the network looks like.
If I cut the wire between Switch 1 and Switch 3, several things need to
happen for Switch 1 to continue being able to send packets to devices
located on Switch 3. The first: Switch 1 needs to know that the cable
has been cut. This one's easy; even the dumbest of dumb switches knows
when the cable's out.
Knowing that the cable is out, Switch 1 should now be able to understand
that all those addresses it thought were available via port 4 now
suddenly can't be reached there. This is where things get complicated.
Looking at the network map, we can all clearly see that to get from
Switch 1 to Switch 3, packets need to be sent to Switch 2. Switch 1 is
connected to Switch 2, which is in turn connected to Switch 3. For a
switch, this isn't so easy to understand.
|
|
