Mon Mar 1 15:01:25 2021
EVENTS
 FREE
SOFTWARE
INSTITUTE

POLITICS
JOBS
MEMBERS'
CORNER

MAILING
LIST

NYLXS Mailing Lists and Archives
NYLXS Members have a lot to say and share but we don't keep many secrets. Join the Hangout Mailing List and say your peice.

DATE 2015-06-01

LEARN

2021-03-01 | 2021-02-01 | 2021-01-01 | 2020-12-01 | 2020-11-01 | 2020-10-01 | 2020-09-01 | 2020-08-01 | 2020-07-01 | 2020-06-01 | 2020-05-01 | 2020-04-01 | 2020-03-01 | 2020-02-01 | 2020-01-01 | 2019-12-01 | 2019-11-01 | 2019-10-01 | 2019-09-01 | 2019-08-01 | 2019-07-01 | 2019-06-01 | 2019-05-01 | 2019-04-01 | 2019-03-01 | 2019-02-01 | 2019-01-01 | 2018-12-01 | 2018-11-01 | 2018-10-01 | 2018-09-01 | 2018-08-01 | 2018-07-01 | 2018-06-01 | 2018-05-01 | 2018-04-01 | 2018-03-01 | 2018-02-01 | 2018-01-01 | 2017-12-01 | 2017-11-01 | 2017-10-01 | 2017-09-01 | 2017-08-01 | 2017-07-01 | 2017-06-01 | 2017-05-01 | 2017-04-01 | 2017-03-01 | 2017-02-01 | 2017-01-01 | 2016-12-01 | 2016-11-01 | 2016-10-01 | 2016-09-01 | 2016-08-01 | 2016-07-01 | 2016-06-01 | 2016-05-01 | 2016-04-01 | 2016-03-01 | 2016-02-01 | 2016-01-01 | 2015-12-01 | 2015-11-01 | 2015-10-01 | 2015-09-01 | 2015-08-01 | 2015-07-01 | 2015-06-01 | 2015-05-01 | 2015-04-01 | 2015-03-01 | 2015-02-01 | 2015-01-01 | 2014-12-01 | 2014-11-01

Key: Value:

Key: Value:

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.


  1. 2015-06-01 Ruben Safir <mrbrklyn-at-panix.com> Re: [LIU Comp Sci] Summer NYLXS Study Schedule
  2. 2015-06-01 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Artifical Intelligence Workshop cancelled tonight for Space Program
  3. 2015-06-01 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Logicworks
  4. 2015-06-02 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] 3d scanning and virtualization
  5. 2015-06-04 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Linux Laptops cheap
  6. 2015-06-06 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Brooklyn Press
  7. 2015-06-07 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] This weeks schedule
  8. 2015-06-10 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Dynamic Network Stacks
  9. 2015-06-17 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Programming and Design contest
  10. 2015-06-18 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] join me for school with a scholarship from the Linux foundation
  11. 2015-06-26 Ruben Safir <mrbrklyn-at-panix.com> Subject: [LIU Comp Sci] Fwd: strange function types in unistd.h

NYLXS are Do'ers and the first step of Doing is Joining! Join NYLXS and make a difference in your community today!