AlexOakenman - Fotolia

Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

LAN SDN management looks to the cloud and causes LAN ghost towns

Future campus LAN SDN management will be needed to deal with LAN applications that have migrated to the cloud, creating on-premises network ghost towns.

Toiling away in labs -- and largely ignored in the excitement over software-defined networking in containers, programmability and software-actuated data centers -- vendors are making real progress on campus LAN management options. In particular, overlay technologies are finally on the ground and are actually making network administrators' jobs easier. But the real explosion in LAN SDN management is just on the horizon, being driven by the cloud -- just not in the way you might think.

We're likely to soon see peak campus LAN complexity, followed by extreme homogeneity. Impossible as it may seem, LAN SDN management will become our preferred mechanism for everyday campus switches and routers. In reality, we won't have much choice.

DevNet, gray hair and aha moments

Cisco Live this year pushed DevNet front and center -- literally. Much like being funneled through the duty-free area on the way to a flight, the DevNet labs, classrooms, meet-the-engineers tables and other stops were right behind the registration area and at least four times larger than last year. Responding to that funnel, throngs of engineers -- from data center superstars to small-company MacGyvers -- spent hours learning about a programmable network future. I saw lots of smiles and more than one aha moment, often from administrators who keep the lights on via IOS command-line interface.

Impossible as it may seem, SDN will become our preferred mechanism for everyday campus switch and router management.

For example, one 30-seat lab was filled for three days with RESTCONF training, a popular topic. As administrators curled the controller to check flow inventory with REST:

https://{controller host}/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/2

They discovered conversations with SDN overlay controllers were easy to understand, as seen below.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<flow xmlns="urn:opendaylight:flow:inventory">

<id>111</id>
    …
    <match>
        <ethernet-match>
            <ethernet-type>
                <type>2048</type>
            </ethernet-type>
        </ethernet-match>
        <ipv4-destination>10.0.0.1/24</ipv4-destination>
    </match>
    …
    <flow-name>DevnetLive22</flow-name>
    <priority>2</priority>
    <barrier>false</barrier>
</flow>

In these controllers, administrators found familiar conventions they already use to configure interfaces and route traffic, wrapped in XML, or extensible markup language, and REST. They learned the metadata mapping demands of application-specific integrated circuits to the will of OpenFlow. And they signed up for DevNet and asked about Cisco programming certifications in droves.

LAN SDN management as the dark horse

Perhaps the eureka moment is realizing SDN isn't simply an application configuration responder to the server room, but, instead, it can manage even far-flung corners of the network. And that's the critical point engineers need to grasp -- when apps move out of our data centers to the cloud and software as a service, future campus LAN won't be about optimizing delivery from the inside. No, future campus LAN will live in the cloud, because that's where the applications setting delivery requirements will have migrated.

SDN brokers at the network edge will need to assess multiple business-critical services advertising their requirements to the enterprise network. They will be able to determine the best configurations to serve the traffic mix most effectively and make the changes themselves -- or at least notify one of the remaining human engineers and make a recommendation for their review.

Take, for example, the opportunity for LAN SDN in capacity planning. Smart SDN and network monitoring systems will make recommendations based on current and proposed service lists, even suggesting infrastructure updates when current network resources can't, or at least not cost-effectively, meet needs. As new hardware, bandwidth or routes are brought online, these SDN monitoring systems will dynamically reprovision based on the new resources made available to it.

With cloud moves come on-premises LAN ghost towns

Consider the future ghost towns of on-premises networks. In many ways, especially for controller overlay, the challenge of LAN SDN automation is considerably less complex than data center SDN. Moreover, it will become even less complex over time as data centers shrink. Our current delivery networks do so many things in so many ways because of the individual needs of specific technologies, applications and hardware. Going forward, considerable IT savings will be realized through massive heterogeneity and standardization.

IT will be the Lego-ization of the LAN, which we saw first with virtualization, and more recently with containers and the cloud. Those administrators having aha moments in the Cisco DevNet classrooms will be the ones not replaced by elastically scalable contractor arrangements, where highly simplified modularity allows specialist engineers to support on-premises hardware at multiple client sites with fewer admins.

Will our once-humming, nuanced and tweak-needy local networks become lonely shells of their former glory, reduced to mundane, commoditized pipes for HTTP? Will human administrators simply feed the machines when prodded? What would it look like if tickets were created by remote change orchestrators -- humans making only the changes the machines can't, the monitors going back to green and administrators going back to playing games? That's already the norm in cloud data centers like Google and Facebook, where single administrators maintain thousands of servers. Is a simplified, data center-less physical network really all that different?

I like to think we'll actually do way more, with higher quality and less effort, using SDN and software actuation for the campus LAN. That's why humans are drawn to mechanization in the first place -- more leisure and removal of the mundane. And based on the real interest in the technologies of SDN I saw this year, I'm hopeful anyone who wants to do networking in a cloud-based world will have plenty to do. If application engineers have taught us anything, it's that changing tools periodically is OK in the end.

Next Steps

SDN can improve network management

SDN pros and cons

How do SDN and wireless LAN work together?

This was last published in September 2016

Dig Deeper on SDN for campus LAN

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

How will SDN management of a cloud-based campus LAN affect the role of network administrators?
Cancel

-ADS BY GOOGLE

SearchNetworking

SearchEnterpriseWAN

SearchCloudProvider

SearchUnifiedCommunications

SearchSecurity

SearchDataCenter

Close