Demystifying SDN For The Network Engineer

Transcription

White PaperCisco PublicDemystifying SDN forthe Network EngineerOut on the IT horizon, there’s achange gathering force that isdifficult for network engineersto ignore. Software-definednetworking (SDN) promisesto be a big change, and thoseengineers surveying thewaters recognize that it is nosimple blip on the radar.Some network engineers have already sailed out tomeet it; others are contemplating it back on shore andwondering at what point it will enter their day-to-daylives. Many are trying to figure out what SDN is aboutand exactly how it stands to impact their work asnetwork engineers.This white paper aims to demystify SDN for thenetwork engineer and, in so doing, help chart thecourse for the journey ahead. The white paper willseek to accomplish the following: Explain the technological forces that have givenrise to SDN Provide an easy-to-understand look at a newnetwork architecture made possible with SDN,and show how the new model compares witha traditional network architecture Discuss why SDN is such a monumental changeand enumerate the benefits it can bring to thenetwork and the network engineer job role Share a couple examples to illustrate how SDNcan dramatically ease the daily function of thenetwork engineer Offer guidance for understanding SDN and takingyour first steps 2017 Cisco and/or its affiliates. All rights reserved.1

Demystifying SDN for the Network EngineerChange Is in Your BloodFirst, in approaching SDN, realize that you as anetwork engineer are no stranger to change. It hasalways been a part of your growth with the network.If you’ve been in the field for 20 years or more, thenyou made the big shift from circuit switching used intelephone technology to packet switching used in IP.And, if you’ve been practicing for 10 or more years,you’ve forged ahead with the progression from ATMand Frame Relay to Ethernet as the preferred WANtechnology and all the network speed benefits thathave come with it. You’ve also moved from wiredaccess to wireless access, and then to convergedwired and wireless networks. In addition, you’ve beenpart of the adoption of Voice over IP and all types ofvideo, requiring a new focus on quality of service andhow to support real-time applications.Finally, look back over just the past decade andrealize that you as network engineers have respondedsuccessfully to widespread adoption of mobile devicesand BYOD policies by figuring out the security andVPN technologies needed to connect the network tomany different end devices. You’ve dealt with IPv4address exhaustion due to mobile device proliferation,and you’ve begun to take responsibility for managingInternet of Things (IoT) devices, exploring deeperanalytics, and implementing virtualized services suchas cloud.To be a network engineer, therefore, is to havewelcomed and embraced change repeatedly overthe years. The SDN change is not minor, but as thiswhite paper seeks to demonstrate, it is a shift thatoffers a great deal of promise for those with continuedadaptability and receptivity to learning in their careers.Why Is This Happening Now?SDN, also known as network programmability ornetwork automation, offers us a way to make thenetwork nimbler by introducing a greater level ofautomation. Before we discuss more precisely howthat gets accomplished, let’s take a look at three 2017 Cisco and/or its affiliates. All rights reserved.White PaperCisco Publickey catalysts in the industry driving the need fornetwork change: Dependence on mobility for digital business Virtualization and the flexibility of cloud services Scaling requirements for the Internet of Things (IoT)Mobility is not a brand new phenomenon, of course,but mobile devices have proliferated in this age of“bring your own device” (BYOD). BYOD has becomethe expectation for connecting quickly, seamlessly, andreliably within an organization. Mobility is the oppositeof static, and therefore network policies must bedynamic and flexible to accommodate mobile devicesand allow users to operate free of artificial constraints.As for cloud, it wasn’t all that long ago that cloudservices didn’t exist. Every organization had its owndata center, and no one thought in terms of shiftingimportant business applications to the cloud for useonly when needed. Nowadays, organizations havedecisions to make about public, private, and hybridcloud options, and along with this has come a needfor agility in network policy enforcement and decisionmaking. The network also requires further reachwith cloud so that the control points of an enterprisenetwork can extend right to where the applications andstorage of information is taking place.And then there has been the rise of IoT with its explosionof new sensors and devices connected to the network.Cisco predicts that by 2030, the number of devicesconnected to the Internet will be 500 billion. And allthose networked devices will require talent to manage.In a bygone time, if an IT networking team had to,let’s say, double the number of network endpointsit supported, it would scale the number of networkengineers on staff accordingly. But with an exponentialrise of IoT endpoints, simply increasing staff to keep upis no longer realistic. There needs to be a more efficientway to scale the network to meet modern demands.Mobility, cloud, and IoT are three very real ways inwhich business is being digitally transformed. And2

White PaperDemystifying SDN for the Network Engineerthe network—the nerve center of it all—has not beenuntouched. While you have no doubt been hearing about“digital business transformation” a lot these days, theyare not just words. Digital transformation has spurredthe need for a digitally ready network. And the way toget there—the way to scale effectively—is to implementa network that is automated and software-driven.When Connectivity Was theBe All and End AllTraditionally, the network has been manual, complex,and static. This was fine for decades, where theprimary goal of the network engineer was this aboveall else: maintain connectivity! Keep the network upand running, and you were doing your job well.To meet this goal, network engineers have mostlyworked at the command-line interface, or CLI,manually configuring a network infrastructure ofdedicated hardware devices one by one. Differentplatforms and products in the network requireCisco Publicmemorizing different sets of commands or lookingthem up. This scenario represents the case for thevast installed base of routers, switches, and otherdevices used in today’s networks.Traditional Network Device ArchitectureNetwork engineers are, of course, familiar with thearchitecture of a traditional network device, such as arouter, which has three operational planes, as shownin the image below: the data plane, control plane, andmanagement plane. The data plane is responsiblefor the forwarding of packets, the control plane usesrouting protocols to decide where packets shouldbe sent, and the management plane provides theability to configure the router using policies that areimplemented by the network administrator. If the dataplane is the hands of the network, the control planeand management plane are the brains.Prior-Hop RouterRouterNext-Hop RouterManagement PlaneManagement PlaneManagement PlaneConfiguration - CLIControl PlaneControl PlaneControl PlaneRouting ProtocolRouting ProtocolRouting ProtocolIP Routing TableData PlaneData PlaneData PlaneForwarding Table 2017 Cisco and/or its affiliates. All rights reserved.3

Demystifying SDN for the Network EngineerWhite PaperCisco PublicThe Programmable NetworkLeave It to the ControllerGoing forward, networks need to be moresophisticated in their incorporation of today’s newservices and technologies, and agile and flexiblein their ability to turn these services off and on asneeded. The way to do this, increasingly, has beento move away from manual, device-by-deviceconfiguration to software-driven, programmaticinterfaces that enable automation.The APIC-EM controller sits in the center of theprogrammable network architecture. The controllerserves as the network information database and controlpoint. Even before learning programming skills, thenetwork engineer can immediately take advantageof the application programming interfaces, or APIs,that allow the controller to implement policies in thesouthbound direction to the network devices.It’s not a brand new concept. There has been somesort of programmatic, software aspect to networkingfor a while. For many years, the data center hasbenefited from SDN technologies. Now these samebenefits are being applied to all segments of enterpriseand service provider networks.Instead of using the typical CLI to accomplish thistask, the network engineer now uses a GUI providedby the controller. This is where the automation magichappens, because instead of requiring the sameconfiguration to be repeated manually on each device,the controller is able to apply the desired policiesacross all devices. The controller also provides APIsin the northbound direction in order to interact withnetwork applications and business applications thathelp to manage, secure, and extract useful data fromthe network.Cisco recognizes that the transition toward networkautomation must allow for legacy networks to migrateover time. In Cisco’s model of SDN, as a first step, themanagement plane has been greatly enhanced andcentralized within a software-based network controllerdeveloped by Cisco for enterprise networks. This iscalled the Application Policy Infrastructure Controller Enterprise Module, or APIC-EM.The image below shows Cisco’s network automationmodel with APIC-EM at its core. Data plane and controlplane functionality continue to exist largely at thedevice level. The controller takes over much of theactivity of the management plane.ApplicationsCisco: Easy QoS, Path Trace. or Third PartyNorthbound APIsControllerAPIC-EMSouthbound APIsNetwork DevicesSwitch, Router, Wireless 2017 Cisco and/or its affiliates. All rights reserved.4

Demystifying SDN for the Network EngineerIn this new world, the network engineer is no longerinteracting through the CLI and monitoring activity andtroubleshooting on a terminal. Instead, utilizing thenew programmatic interfaces and prebuilt networkapplications, the controller-based architecture isable to greatly automate and streamline these tasks.The interaction is no longer human-to-machine butsoftware application-to-network device.You can now rely on the controller to determine theplatform-specific configuration commands and syntaxinformation to send to each network device. You use anintuitive GUI to tell the controller what business policyyou want to implement, and the controller is able toconvert the intended policy via APIs and translate theseinto the myriad rules and applicable configuration forthe different devices in your network.You are freed from much of the need to memorizecommand syntax because you can simply provide thecontroller with a policy and let the controller managehow it is going to interact with each device so thatthey can be configured, modified, or set up to achievespecific business goals.The APIC-EM controller has a network informationdatabase that allows you to scan the network andobtain an inventory of all network devices. With thisimproved visibility into the network, APIC-EM thenautomatically configures every device that has beendiscovered as part of the inventory.Big Change, Big PayoffIn the changes that network engineers have greetedover the years, SDN is monumental in that theautomation of network processes through softwareallows the necessary agility, flexibility, and scalability inthe network that mobility, cloud, IoT, and other aspectsof digital business transformation demand. Duringthe coming years, organizations in every industry willbe unable to claim digital readiness unless they haveacquired some proficiency with network automation.For organizations and network engineering teamswilling and able to evolve to a controller-basedarchitecture, the benefits will be substantial. Here aresome of the specific rewards to be reaped: 2017 Cisco and/or its affiliates. All rights reserved.White PaperCisco Public Greater speed and thus faster rollout of services:If you’ve got a network change to make, you cannow take advantage of a network application thatautomates the process. Traditionally, if you have tomake the change to hundreds of routers, you needto do it manually at the CLI, one router at a time overthe course of hours or days. With automation, yournetwork application can configure all routers in amatter of minutes. Accuracy and reliability: If you use a validatednetwork application, then you know it is always goingto be done consistently. Conversely, if you have todo something manually across a hundred devices,chances are good you’re going to make an error onat least one of them. Simplicity: The controller uses a process calledabstraction to translate complex rules and policiesbehind the scenes to make things transparent to youthe network engineer. Ability to optimize the network: With programmability,you can get the network to respond much morefluidly to constantly changing conditions. Youcan optimize the use of resources and adjust tochanges automatically, which further increasesnetwork efficiency and speed. You can scale networkservices up or down per business demands. Better analytics: A truly digital network allows youto get deeper data and faster insights, which allowsyou to be more agile and improve security visibilityby learning from and adapting to changes andneeds in the network. Greater OpEx value: This white paper spokeearlier about how IT teams will continue to confrontstaffing demands in the face of IoT’s massive scale.Automation can relieve the situation by enablingnetwork engineers to accomplish more with thesame effort and time expenditure. This benefit isparticularly motivating when one considers thatoperating expenses (OpEx) can account for twice asmuch as capital expenditures (CapEx) in enterprisenetwork deployments.5

Demystifying SDN for the Network EngineerAha, I See Why This Matters!Let’s look at a couple compelling examples of how SDNcan ease the daily work of a network engineer. Workingwith access control lists, or ACLs, requires exactsyntax and sequencing to achieve the required securitycontrols. Configuring and troubleshooting ACLs canbe a complicated and cumbersome task for networkengineers. These rules about how traffic can flowthrough the network and who can have access canget unwieldy as the list of permissions and constraintsconfronting the user at the CLI builds up over time.Eventually, the ACLs can get so long that they begin todevelop inherent contradictions, as earlier permissionsand constraints get forgotten with the addition ofnew ones. ACLs can sometimes contain hundreds ofentries, and sorting through them can feel like trying tofollow a very complex logic diagram. 2017 Cisco and/or its affiliates. All rights reserved.White PaperCisco PublicOne big advantage of the Cisco APIC-EM controlleris that it vastly simplifies and accelerates ACLmanagement with an application called the Path TraceACL analysis tool. The Path Trace ACL applicationgathers ACL information from each network deviceand shows the hop-by-hop path taken (or blocked) bytraffic between endpoints. Path Trace ACL is a particularboon to the engineer, because the APIC-EM controllerautomatically determines all of the permissions andconstraints automatically. Rather than confronting youwith a tangle of logic at the CLI, a visually friendly GUIgreets the engineer at the computer, revealing in shortorder, by means of easy-to-interpret graphics, exactlywhich device is blocking traffic.The two screen shots below show the Path TraceACL GUI within the APIC-EM controller, and its abilityto pinpoint in a highly visual, straightforward mannerwhere network traffic is getting blocked.6

Demystifying SDN for the Network EngineerHard QoS vs. Easy QoSThe simplicity and user-friendliness of SDN alsobecomes dramatically evident when one looks atthe Easy QoS feature that comes with the APIC-EMcontroller. Typically, network engineers configure QoSin the network on each device. The ability to manageand prioritize network traffic and real-time applicationsrequires QoS to be configured across all networkdevices in a path. If there are 10 hops in the pathbetween the sender and the recipient, each one ofthose devices must be configured so that it can operateaccording to which packets merit the higher priority.The network engineer might spend 10 or more minutesconfiguring each hop. And then, if a new businesscritical application needing priority appears on the scenethe next day, the network engineer must reconfigurethe entire network so that this new addition to networktraffic gets high-priority treatment.Because it can be so burdensome to implement, manyusers do not fully utilize QoS. Instead, they acceptthe expense of overprovisioning the network to avoidcongestion. This is a costly and inefficient way tooperate networks.But now, with the burgeoning of IoT and its myriaddevices, you can’t, for example, have a smart vendingmachine getting the same priority as a quarterly salesreporting database—there’s just too much dependencyon timely access to information. Gone are the dayswhen you can simply provide a “best effort” trafficmanagement to all users and applications.Easy QoS solves this problem. With this feature, thenetwork engineer can simply take advantage of theprebuilt capability within the APIC-EM controller and,using the GUI, select the person, group, device, orapplication and assign the appropriate priority. Oncethe engineer has assigned that business priority,the controller communicates that information via thesouthbound APIs to each device, and implements thepolicy by automatically configuring each device. Whatyou used to have to do hop by hop, you can now do atone central location in the controller. 2017 Cisco and/or its affiliates. All rights reserved.White PaperCisco PublicClick here for a video that illustrates the features ofEasy QoS. The video demonstrates how a user canset a QoS policy via GUI and then let the controllertranslate that request, within minutes, into an end-toend, validated, device-level configuration based onbest practices. The video also shows how you canimplement real-time prioritization of application flows.What About My Needs?While the organizational benefits of SDN are abundant,they also hit home on a personal level for the networkengineer. For one, there is no denying that existencecan sometimes get tedious at the CLI. “Did I put thatcommand in?” “Did I add the right suffix to make itbehave differently?” Network automation can removemuch of the mundane and robotic from daily life.In addition, release from some of the configurationtedium will free up avenues for applying more creativityon the job when you are able to programmaticallycontrol the network. This responsiveness greatlyelevates the value of IT to the enterprise and canextend your visibility into other parts of the business,and kindle the fire of new ways that you can contributeto digital business success.Lastly, as you get ahead of the curve trying tounderstand the benefits of a controller-basedarchitecture and learning about some of the network’sautomation capabilities, you are potentially improvingthe efficiency of the organization and reducing youremployer’s costs. Your increased efficiency andexpanded skills will make you more valuable to youremployer at all levels of engineering responsibility.Charged Up for the ChangeWe hope that our efforts in this white paper todemystify SDN also serve to reduce some of theanxiety that can come with change. But, we realize thatnetwork automation requires a pivot at the architecturallevel and so is not a small change. A “Cisco CertifiedCommunity Research Survey on Network Automationand Programmability,” conducted in 2016, revealedthat 58 per

The white paper will seek to accomplish the following: Explain the technological forces that have given rise to SDN Provide an easy-to-understand look at a new network architecture made possible with SDN, and show how the new model compares with a traditional network a