Discover Cisco’s approach to software defined networking and how Federal Agencies can use network programmability and onePK to enhance their business and mission:
One of the great challenges of SDN – that many in my view underplay – is the change in paradigm from having a vendor deliver your network (hardware + software), to having (potentially) an ecosystem deliver your network – and this ecosystem may require you to develop software to perform network tasks or to integrate various SDN components together. This was recognized quite astutely by consultant Jim Metzler, which I discussed in one of my earlier blogs. “Applications can dynamically request services from the network” is what the SDN evangelists will tell you. Jim astutely asked “How exactly do they do that?”. Well ….. the true answer is that either (i) you need to buy [new] apps that do this off the shelf, as it were, or [more likely today] (ii) you need to modify your apps or develop new apps to do this.
So are you ready for procuring apps and/or developing software in your network design team now? Don’t worry if you say “no”. Let me first tell you a few customer reactions to this topic, and then let me update you on Cisco Services can help you develop new SDN apps that solve your specific network challenges.
I am not qualified to discuss it much, but can you guess what this does?
ne = NetworkElement("172.16.66.1", "JasonsApp")
conn = ne.connect("admin", "cisco", sc)
intf1 = ne.get_interface_by_name("FastEthernet0/1")
If you guessed that it logs into a switch at 172.16.66.1 and disables interface F0/1 for 5 seconds and re-enables it, then you guessed right.
Let us talk a little about putting the “ability” in programmability. Did I code in college? Yes. Was I good at it? Not really. Dijksta’s algorithm (the actual coding bit) drove me crazy, however, actually using and operating networks quickly became my cup of tea. I became a network geek. Subnets? Awesome! Cisco CLI? Sweet. Using Enhanced Interior Gateway Routing Protocol (EIGRP)? Yay! AVVID? Even better. But I never wanted to see C++ or another “program” again.
Fast forward to 2014. I’m still a networking guy but now I’m seeing code again. The good news is, maybe like you, I hang out with some really cool people. I challenged a couple of them to help me demonstrate program “ability” to networking people on the show floor at CiscoLive Milan…with me as the test subject! Read More »
Current differences in app development on devices and controllers disappear. Devices and controllers will share a common programming environment – offering a unified development and deployment experience.
While SDN is moving from concept to reality, we notice that many deployments which focus on creating new network features interpret the role of the “controller” very pragmatically. In these deployments, the controller is not used as an independent layer of software which abstracts the entire underlying infrastructure as in the traditional view of SDN (see for example ONF’s SDN Definition). The pragmatic approach to network programming simply extends the distributed development environment of the network devices using a set of qualities offered by the controller. Developers move those components of their distributed apps to the controller that benefit from the logical centralization or the enhanced resources (CPU, memory) that a controller typically offers while keeping other components on the network devices. Example use cases fall into the categories of distributed network analytics, DDoS thread mitigation, or routing optimization based on performance measurements. What does this mean for our development environment?
The other week I attended the “Software Defined Networking 2013” conference in London. This is a UK-based event for the discussion of SDN, OpenFlow and Network Virtualisation Solutions from a strategic perspective. There were quite a few interesting perspective s I picked up at this conference. In particular, the conference for me reinforced the potential of SDN – but if you apply it to the wrong problem, you may not get the return you hope for!
Top of mind for me, then, coming out of this conference was a demo of “What SDN Can Do For You” from one of our competitors. At best, the phrase “using a sledge hammer to crack a nut” comes to mind.
The demo came from our friends in Palo Alto, who once (boldly but incorrectly!) predicted that “Cisco UCS would be dead a year after launch”. They gave a SDN-focused demo that, when I “peeled back the onion”, didn’t demonstrate a compelling SDN use case. Rather, it convinced me that if you have this particular problem as illustrated in their demo, you don’t need SDN: you need a new vendor!
Tags: ACI, application centric infrastructure, architectural approach, Cisco collaboration, Cisco Services, Cisco WebEx, jabber, Jabber Video, network virtualization, onePK, SDN, software defined network