Change is the only constant. Except that it isn’t; constant that is. We are seeing changes to IT services, infrastructure, eco-systems, and business models, with consequent demands and expectations that we have not witnessed before. Cisco is responding to all of this with new technologies for the DevOps community, including APIs, development tools, training and more, all of which I discuss below.
The Economist likens this to the Cambrian era that saw the multiplication of life forms that populate our world today: “… this time is … different, in an important way. Today’s entrepreneurial boom is based on more solid foundations than the 1990s internet bubble, which makes it more likely to continue for the foreseeable future.”
What has made this possible, which the Economist illustrates with a variety of examples, is the ubiquity of communications and open source platforms in a “cloud” environment. The Economist lists these elements:
- …snippets of code that can be copied free from the internet, along with easy-to-learn programming frameworks (such as Ruby on Rails).
- … services for … sharing code (GitHub) …
- … “application programming interfaces” (APIs), digital plugs that are multiplying rapidly …
- … “platforms”—services that can host startups’ offerings (Amazon’s cloud computing), distribute them (Apple’s App Store) and market them (Facebook, Twitter).
- … the internet, the mother of all platforms, which is now fast, universal and wireless.
What has also changed is that the IT stack is, in effect, collapsing. The “separation of concerns”, that kept the network infrastructure distinct from the applications running over it, is being whittled away. In October 2013 we teamed up Read More »
Tags: #ciscochampion, #CLUS, ADN, APIs, Cisco onePK, Cisco Open Network Environment, ciscolive, open network, Open Network Environment, SDLC, SDN, Software Development Lifecycle
CiscoLive San Francisco is coming up so I’ve been updating my session, the Hitchhiker’s Guide to onePK, with the latest information and some new insights.
One new thing is that Cisco onePK (One Platform Kit) is now Generally Available! Anyone can go to onepkdeveloper.com, download the SDK, and take C, Java or Python for a test drive. And I really mean anyone. You don’t even need a Babel fish. Haven’t programmed since freshman year in college? Don’t worry. If you can click on an icon in a Linux desktop and type the name of a script, then you can use onePK.
The great thing about this is that now we can all get real. As a network engineer, technologies aren’t real to me until I see them running on a network. After all, you can read about LSA types and adjacencies all day long, but until you’ve deployed OSPF, you don’t really know OSPF. The same is true for onePK. Read More »
Tags: #CLUS, APIs, cisco live san francisco 2014, Cisco Live! 2014, Cisco onePK, ciscolive, developers, Giveaway, one plat, onePK, onepk api sdk ios xe xr nx, sdk
Few days ago, the Networking Industry “who’s who” gathered in Paris for the fourth edition of v6 World Congress http://www.uppersideconferences.com/v6world2014/v6world2014introduction.html. I’m very proud that Cisco has been sponsoring and supporting this IPv6 Conference since its inception. It is always a very special feeling to have so many industry leaders visiting my hometown. This event has become a milestone in the global deployment of IPv6. Paris is the place to be in March each year, if you want to get a status update of IPv6 transition, one of the most important technology transition the Internet have ever gone through.
I want to share what I personally consider, the most important take-away of the week. Read More »
Tags: Alain Fiocco, Cisco 6lab, ipv4 exhaustion, IPv6, USGv6, World IPv6 Launch
The proliferation of different types of device interfaces places a significant burden on application developers and equipment providers alike. One of the reasons for the rise of Software Defined Networking (SDN) is its promise to simplify management by providing a single point through which the entire network can be managed and administered. This raises the question whether this promise extends towards dramatic simplification of the device interface landscape as well, specifically, whether SDN can put an end to device interface proliferation and in the future a single management and control interface may be all that is required. Unfortunately, it turns out that this particular hope is unsubstantiated. Here is why.
The Promised SDN Land of Interface Simplification
Much has been made of the need to align the various interfaces through which networking devices can be managed and controlled. It has been difficult enough to just keep SNMP implementations consistent. Throw CLI, syslog, and Web Services into the mix, and the task becomes daunting indeed. One reason why different interfaces have to be supported has to do with customer preferences, of course. Chef is the new paradigm to support? Sure, we’ll add that. ReST is becoming en-vogue? We’ll support that too.
In the middle of all this, along comes SDN. “Don’t bother with individual devices and their legacy interfaces” is the siren call. “Use a controller to orchestrate the network instead” – a single point of control through which the network can be operated and maintained, an enticing value proposition indeed. Early SDN technology such as OpenFlow made a big splash and gained a lot of mind share this way. Rather than messing with the hodgepodge of existing interfaces, a single interface was introduced to control OpenFlow switches. Just support this one interface, or so the message went, and your equipment can join the New World of Software-Defined Networking, leaving the Old World of fragmented interfaces behind, much like early European settlers coming to America hoped for freedom and a better life, leaving behind constantly quarreling fiefdoms and many centuries of historical baggage. Read More »
Tags: Cisco SDN, control interfaces, device management, SDN
Extensive Message Protocol (XMPP) is an open standard protocol based on XML (Extensible Markup Language). XMPP is designed to transport instant messages (IM) between entities and to detect online presence. It supports authentication of IM application and secure transport of messages over SSL/TLS. In XMPP entities can be bots, physical users, servers, devices or components. It’s really a powerful tool that has great potential for system administrators to add to their toolbox because:
- XMPP is powerful
- XMPP with Python is only 12 lines of code – trust me, it’s easy!
- XMPP only requires a single query for multiple nodes
- Status message can be used to track host presence
The Power of XMPP
For those of you that are not familiar with XMPP, it not only supports one-to-one messaging between entities but it also supports multi-party messaging (which enables an entity to join a chat room for the exchange of messages with several participants). The messages can be text messages embedded in XML format but XML can also be used to send control messages between entities as we will see with the presence stanza in a bit.
XMPP is widely used; Google uses it (for its Hangout application – formerly google chat) and so does Yahoo and MSN. At Cisco, we use Cisco Jabber extensively to communicate internally. The XMPP client function is now integrated in the Cisco Nexus 5000 series with the release 5.2(1)N1(7) and the Nexus 6000 series with the release of 7.0(0)N1(1). XMPP is an integral part of the single console access for Dynamic Fabric Automation (DFA) which is a powerful framework described in my previous blog.
The new Data Center Network Manager (DCNM) 7.0(1) is delivered as an OVA file that can be deployed quickly on an existing VMware-enabled server. Although DCNM comes with a lot of features that simplify the deployment of the Data Center fabric, we can pick and choose any service we want to use independently – which is great since DCNM comes with Cisco Jabber XCP and is license free. If you already have a XMPP service installed (like Openfire or ejabberd), it will not be a problem because everything discussed here is valid on any standard XMPP implementation.
On NX-OS devices, the XMPP feature is activated by configuring ‘feature fabric access’ and is part of the Enhanced L2 license (ENHANCED_LAYER2_PKG). Once activated, the switch becomes a XMPP client that needs to be registered on the server. In order to register it, XMPP requires the use of fully qualified domain names (FQDNs) to identify the domain server. If the switch does not have access to a DNS service, I recommend that you use the switch management network for messaging and a static host–to–IP address mapping in the switch configuration.
The switch will use its hostname to login to the XMPP service. If your XMPP server does not support auto-registration, you will need to register the switch and the rooms in the XMPP database beforehand. The DCNM OVA requires users and groups to be created via the CLI, and example of this user and group creation is:
[root@dcnm-ova ~]# appmgr add_user xmpp -u leaf0 -p cisco123
[root@dcnm-ova ~]# appmgr add_user xmpp -u leaf1 -p cisco123
User added. Read More »
Tags: Cisco Data Center Fabric, Cisco Nexus, DCNM, instant messaging (IM), NX-OS, open standard protocol, XML, XMPP, xmpp with python