This blog is part of my series on Devops for Networking. onePK is Cisco’s attempt to expose a standard set of APIs to configure and monitor across multiple different Cisco devices. Orchestration and automation applications can use these standard APIs to talk to Cisco devices. In this blog, I will cover a brief overview of onePK and how to get started with onePK to write applications on top of it.
Following block diagram from Cisco gives different blocks involved in onePK.
This blog is part of my series on Devops for Networking. As I indicated in 1 of my earlier blog, majority of Network devices still have CLI as the only means of configuration and monitoring. CLI is not automation friendly because of obvious reasons. In the last few years, Cisco NXOS devices provides CLI output in XML and JSON format. This allows much easier ways to parse the CLI output which aids in automation. In this blog, I will cover some examples of monitoring Cisco NXOS devices using Python interface to interact with the device and get useful information.
Continue reading Nexus devices CLI parsing using Python, XML and JSON
This blog is part of my series on Devops for Networking. In this blog, I will cover a brief overview of UCS management model, management tools and how to automate configuration and monitoring of Cisco UCS using Python SDK. UCS is Cisco’s Unified computing system that provides a tightly integrated compute, networking and storage solution.
Cisco UCS management information model is a hierarchical tree with each node in the tree representing either physical or logical entity. The node is referred to as MO(Managed object). Physical entities could be chassis, servers, switches and logical entities could be policies, service profiles etc. XML based interface is provided to set and get managed objects. Following picture shows a sample Management tree with Chassis, blades and adapters.
Devops is now a widely used term. I recently read few articles on Devops in relation to Network Automation and that prompted me to do some research on this topic. In this blog, I will cover what I think comprises the Devops Networking domain and in the next series of blogs, I will try to explore individual areas in more detail. Devops allows infrastructure to be treated as a code and it makes the infrastructure programmable. The term Devops refers to a merger between Development and Operations role and it encourages Developer to look at Operations angle and Network operator to look from Developer angle. As everyone knows, automating infrastructure deployment improves efficiency, removes operator error and allows us to scale. Server automation has been present for quite some time and Network Automation is still very much in infancy stage at this point. Following article from Ivan describes Devops as a lifestyle or mindset on how infrastructure is treated rather than as tools associated with Devops.
This blog is a continuation from my previous blog on SDN Openflow commercial applications. In this blog I will cover SDN applications in Network performance optimization and monitoring and Data center fabric.
Networks have a lot of information and by looking at Network state and statistics collectively rather than at individual device level provides a lot of useful information. This information can be used to optimize the network based on application needs. The next set of applications are targeted towards monitoring Network state and statistics as well as improving the performance of the network.
Kemp has integrated its Load master ADC with HP VAN SDN controller to provide adaptive load balancing based on the traffic load on the switches. Normally ADC makes load balancing decisions based on L4-L7 characteristics. Kemp’s Load master ADC interacts with HP VAN SDN controller which in turn gets the traffic load on switches using Openflow. Based on the L2/L3 network statistics and the L4-L7 characteristics, Kemp’s Load master makes intelligent decisions on traffic steering and load balancing.
Continue reading SDN Openflow commercial applications – Part 2
In this blog, I will cover some commercial SDN Openflow applications available in the market now. SDN is the most overused term in the Networking industry now and there are different applications and technologies claiming as SDN. I am going to cover SDN Openflow applications which rely on the model of switches supporting Openflow agent and a centralized controller running the control plane and programming the data path in the switches using Openflow protocol. The switches can either be virtual or physical switches. Following are the topics that I am planning to cover in this blog.
In the first blog, I will cover the SDN Openflow application model and TAP monitoring fabric and Security applications. In the next blog, I will cover Network performance optimization and monitoring, Data center fabric and some final thoughts from my side.
Continue reading SDN Openflow commercial applications – Part 1
This is a continuation of my previous blog on White box switches. White box switches allows for dis-aggregation of switch hardware from the software running on the switch. This approach allows the buyer to purchase hardware from 1 vendor and software from another vendor. Open compute project is an Open source project that was started around 4 years back by Facebook to open up the Data center hardware. Multiple other companies like Intel, Microsoft, Goldman Sachs have joined the community since. Around a year back, Networking charter was started in Open compute project to open up the Networking part of Data center hardware. Facebook, Intel, Broadcom, Cumulus, Arista are some of the vendors participating in this project. In this blog, I will cover the following:
This is a continuation from my previous blog on NFV overview. In this blog, I will cover popular NFV solutions in the market. This is not an exhaustive list, these are the NFV solutions that I am aware of. Following are the ones that I will cover:
Network function Virtualization(NFV) refers to Services running on commodity hardware(compute, storage, network) which replaces functions that are done in specialized boxes currently. This applies mainly to Telecom sector, but the same concept can be extended into other areas as well. If we look at current products in the Telecom sector, there are separate hardware systems for each functionality. Examples of these systems are CPE switches, BRAS, LTE, mobile backhaul, firewall, load balancer etc. In all these systems, there is a tight coupling between the software stack and the hardware supplied. This causes multiple issues to the carrier/operator like high capital cost, multiple management systems, dependency on few select vendors etc. In the initial days, one of the reasons for using specialized hardware was that general purpose servers did not have enough horsepower. Newer generation servers pack in a lot of horse power that allows both control and data plane functionality to be done with commodity servers. This in addition to the maturity of Virtualization technologies(compute, storage and network) have made NFV more practically possible now. There will still be some scenarios where it is necessary to use hardware systems with ASICs for high throughput and distributed processing needs etc.
In this blog, I will cover the following:
In the next blog, I will cover popular NFV implementations available in the market today.
Cisco’s acquisition of Tail-f prompted me to look deeper into what Tail-f does. That in-turn made me dig deeper into Netconf and Yang. Netconf is a device configuration and management protocol and Yang is a modeling language that’s used by Netconf. Yang modeling can also be used outside Netconf’s context. From looking at the history behind Netconf and Yang, I realized that Network management as a whole was a widely ignored topic for quite sometime. The current Network management techniques used by Operators seems to be very arcane and the recent SDN wave has triggered a renewed interest in simplifying Network management. In this blog, I will cover the following:
