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 »
Tags: #CLEUR, Cisco Live Milan, Cisco ONE, networking, onePK, programmability, Programming with Python, python
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?
Read More »
Tags: controller, Network programmability, onePK, SDN
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
Cisco Live Milan is around the corner and I’m getting my session, The Hitchhiker’s Guide to onePK, ready for it’s European debut. While it’s lovely to be in the CiscoLive Distinguished Speaker Hall of Fame, putting a good presentation together hasn’t gotten any easier. The hard questions still need to be asked: Do I have too many slides? Have I crossed the line between technical and boring? Will the demos work? Will anyone laugh at my jokes?
And perhaps most importantly for this session: does anyone read Douglas Adams any more?
Here’s why. I borrowed the title of Douglas Adam’s iconic Hitchhiker’s Guide to the Galaxy for good reason. The original Hitchhiker’s Guide follows an ordinary guy, Arthur Dent, as he is unwillingly dragged into an intra-galactic adventure, with little more than the Guide, a pint of beer and a packet of peanuts to see him through. Faced with the vast and confusing world of Software Defined Networking (SDN) and programmability, network engineers are in a position to know exactly how Arthur Dent felt. New buzzwords, emerging standards, an abundance of marketing slides with vague but brightly colored blobs, and a lot of talk about programming languages can be disorienting to the best of us.
Enter the Hitchhiker’s Guide to onePK.
Notice that I did not call my session the Hitchhiker’s Guide to SDN. SDN calls for more of an Encyclopedia Galactica than a Hitchhiker’s Guide, if you know what I mean. Instead, my aim is to take a deep dive into one aspect of network programmability that network engineers can really relate to: onePK. Read More »
Tags: #CLEUR, cisco live, Cisco Live Milan, Cisco onePK, One Platform Kit, onePK
We’ve been getting a lot of great questions about ACI since our launch as people try and better understand the value of an application-oriented approach. I got the following questions on my blog post about the Application Virtual Switch that probed on some of the thinking behind an application-aware architecture, and why now was the right time to release it (after all, John Chambers called it the most disruptive Cisco innovation in a decade!). Anyway, on to the Q&A:
I’d like to know more about the path that Cisco pursued to evolve towards an “application aware” architecture. This back-story (how Cisco arrived at this juncture) would be very helpful to industry analysts, customers and institutional investors. Here’s some of the key questions on my mind.
- What were the primary roadblocks that inhibited the adoption of this innovative approach in the past?
I would say that the Application Centric Infrastructure (ACI) was a combination of a Eureka! moment, that people just never thought of it before, and that it was also an insightful evolution from early SDN technology. So, it might be fair to say that SDN had to come along, and then we realized, here might be a better way to program the network (with an application-oriented model, rather than a network-centric model).
That might be another way of saying that the lack of SDN as a precursor to ACI was a roadblock. But I think of it as networks were just built on hardware that were optimized to pass packets and other very specific tasks. And the limitations of historical networking protocols and traditional network designs, coupled with very limited ways in which you could manage a network and tell it what to do, all served as roadblocks to implementing anything like ACI. So the roadblocks that had to be cleared included the ability to program switches through software interfaces, and to centrally manage the software applications or controllers to orchestrate the broader network, not an individual device. Those are some of the things SDN brought along.
Read More »
Tags: ACI, APIC, application centric infrastructure, Cisco ONE, nexus, onePK, OpenFlow, SDN, XNC Controller