OpenStack and OpenDaylight for Network Professionals

Disclaimer: I wanted to name the post "OpenStack for dummies", but I took a wild guess that CCIEs don't really like to be called dummies, so I "tuned" the title a little bit. You're welcome :)


* OpenStack *
Cisco has nothing to do with them Open Source communities, right? No! In order to get your attention I'll just throw a statement out there - A big part of WebEx runs over OpenStack!!!

Ok, now that I've got your attention - OpenStack is basically a Cloud OS, and it's built as a group of components that use APIs to communicate to each other. Yes, there are many more, but OpenStack is the one that's been dominating the market, and the one that will be in 5 years as popular as Virtualization is today. It's mostly written in Python (yes, Python, and if you want to learn a programming language and you're a Networker - I recommend this one). OpenStack has APIs used for components to be able to "speak" to each other. Centred at IaaS, and slowly moving towards PaaS (Platform as a Service)

Have in mind that in order to have a true OpenStack deployed, you can't just have one of the components of the OpenStack. You need to use the original non modified Projects (at least Nova, Neutron, Swift, Cinder, Horizon, Image and KeyStone). Let's talk about what these are. The main components of the OpenStack include:
- Nova - Hypervisor interaction, houses VMs
- Keystone - Identity policies, RBAC, LDAP
- Telemetry - Metering and Monitoring
- Heat - Template based ORCHESTRATION, faster application development
- Trove - DBaaS (Data Base)
- Neutron (called Quantum before, changed due to the proprietary name) - in charge of NaaS part, plug-ins for external HW, IP address management. This is probably the most important component for us, as Networking Professionals, so I'll say a few more words about it. Neutron is designed as a Neutron Server, programmed to integrate with APIs. These are the most important concepts regarding Neutron integration:
- The main one is called CORE API (Network, Port and Subnet).
- The other APIs are called Resource and Attribute Extension API (ProviderNetwork, LBaaS, FWaaS, VPNaaS, Router, SecurityGroups...)
- There are also Plug-ins, like the one in Nexus, that provisions the resources required by the OpenStack in Nexus Switch. Cisco developed ML2 (Modular Layer 2) Plug-in, that contains Type Drivers (VLAN, GRE, VXLAN) and Mechanism Drivers that decide how it's going to be implemented (APIC, OVS, Nexus, OpenDaylight)
- Cisco ACI, instead of constructing the connectivity the application requires, it works on top of the Neutron API evolution so that it builds a per-tenant resources (Network, Router, Security Group, Port)
- Group Policy Neutron API developed for Juno OpenStack release, and it introduces a concept of Contract (set of Policy Rules) between the EPGs (End Point Group)

OpenStack, just like Linux, has it's distributions. Another similarity to Linux is that big clients prefer wont be satisfied with just any OpenStack distribution. They will require a distribution with the Full Product Support, so there are SUSE, RedHat (that has both, Open Version & Enterprise Version), and many others.

CISCO keeps being highly involved in OpenStack, and it's got direct contribution in the following:
- High Availability Architectures (By default OpenStack isn't designed as a HA environment)
- Automation (Puppet). Cisco designed a few installers for OpenStack.
- Neutron/Nova Plug-ins for Nexus, DFA, APIC, UCS
- OpenStack based "Global Intercloud" hosted across Cisco and Partners Data Centres
- CVD (Cisco Validated Design) for various production deployments


* OpenDaylight *
It's an Java based SDN controller that enables the Virtualization as well as the NFV  implementations. OpenDaylight integrates with OpenStack using the Neutron API / Neutron Plug-in.

Cisco has 2 different SDN controllers.
- Cisco APIC (Application Policy Infrastructure Controller). APIC is the main component of the  Application Centric Infrastructure (ACI) fabric, and it's is a product I've been impressed with recently, and I'll definitely dedicate it an entire post.
- Cisco XNC (Extensible Network Controller) is a Cisco's OpenSource SDN controller. Basically it's Ciscos version of the OpenDaylight Controller.

APIC and XNC will have the same Northbound interface. APIC isn't only the SDN controller, but also gives the visibility of what's happening (HealthCheck and other monitoring tools). It's not multi vendor, meaning - it will be profoundly integrated with the Cisco Nexus Series, so in my opinion Cisco has the XNC only as a "just in case" solution, cause if OpenDaylight wins the SDN market, but it will force APIC with all it's got. Most probably the strategy will be to try and offer APIC + Nexus + UCS as the Premium Solution.

Are Cisco Nexus 1000v, CSR 1000v and Vyatta the same thing?

Brief version: No, they are not.

Long version: No, they are not. Nexus 1000v is used for L2 interconnection of the VMs. On the other side, Cisco Cloud Services Router (CSR) 1000v is, in my opinion, a direct competitor of Vyatta /vi:áta/ (acquired by Brocade IN 2012). [Don't make a mistake of underestimating Vyatta, it's a nice and nifty product]. CSR 1000v was introduced by Cisco with the strong message that it will improve the multi-tenancy mechanisms in the Data Center architecture. Why are these improvements necessary, don't we already have VXLAN, NVGRE? Encapsulation can be done using these 3 mechanisms::
- NVGRE (GRE with the key)
- VXLAN (over UDP with proprietary header)
- STT (fake TCP header, so security tools generate alerts, also FW would drop it cause no SYN packets). It can be used between the Hypervisors only.

Well, there are two problems with these solutions. Number 1: None of these 3 has the security, and Number 2: Some clients just want to provide the multi-tenancy using the L3 tools.

CSR 1000v is just a VM, deployed under an ESXi as a Virtual Router. It’s not a structured web of relationships between VSM (Virtual Supervisor Module) and VEM (Virtual Ethernet Module) like the Nexus 1000v. It's a single VM, loaded as a single appliance, with multiple virtual NICs (vNIC), representing ROUTED interfaces. It's these interfaces that extend the L3 boundary into the Virtual Environment. Cool, right? Even more so when you realize it's actually adding a security boundary, with no latency impact.

Here are some interesting facts about the CSR 1000v:
- CSR 1000v supports DMVPN, one of the new features of CCIE RSv5 curriculum.
- Supports all the routing protocols from the CCIE RSv5 curriculum.
- Works with (almost) all the Hypervisors.
- Has the APIs to integrate with the OpenStack
- Cisco ASR 1000 Series Router was used as a "model"
- Multi-tenancy achieved by mapping VPN instances directly to VPC

Here are 2 diagrams that I found on the keepitclassless.net, and I think they perfectly "paint" how the CSR 1000v should NOT (1st pic) and SHOULD (pic 2) be deployed.

Pic 1: CSR 1000v, deployed using the classic non-virtual phylosophy

Pic 2: CSR 1000v deployed in accordance with Virtualization and Multi-Tenant requirements 

And now, some facts about the older Virtual L2 brother, Nexus 1000v:
- It's a SWITCH, so - L2, a product of a partnership with VMware.
- QoS, ACLs, NetFlow and ERSPAN are all supported. Also, VXLAN is supported :)
- Security Features are also supported (Dynamic ARP inspection, IP source guard, DHCP snooping)
- Provides advanced NX-OS features
- Cisco Nexus 1000V architecture follows the same hypervisor-agnostic architecture used across other hypervisors (VMware vSphere, and Microsoft Hyper-V). It has two components: Virtual Ethernet Module (VEM) is deployed on each physical host managed by Nexus 1000V as part of the KVM hypervisor, and Virtual Supervisor Module (VSM) can be deployed as a virtual appliance on any KVM host, or on a Cisco Cloud Services Appliance.
- Yes... It's VERY demanding, so better prepare a good hardware...

Now, I just couldn't finish the post without mentioning Vyatta.
- It's a single (Virtual) image that has Router, FW (State-full with NAT, but not DPI for now), VPN.
- Supports any hypervisor, and Amazon Cloud (and any other cloud), can run on bare-metal.
- Creates multiple tenant spaces, where each tenant has the complex space including the L3 and FW features.
- The entire deployment phylosophy that applies to the CSR 1000v - also applies to Vyatta. Let´s see how much of an open mind do the new era customers really have, and let´s see how the prices adjust.

Network Virtualization vs SDN

SDN (Software Defined Networking) and Network Virtualization, although often in the "same basket", are two different concepts.

Network Virtualization (NV) decouples and isolates "virtual" networks from the underlying physical network hardware. SDN is a concept of separating the Data plane from the Control plane. It does look similar. The NV analogy can be made with the Server Virtualization, which has been the most frequently deployed solution in the Data Centres for quite some time now. In my opinion probably the most important term related to NV is the concept of PROVISIONING. What could this mean in Networking terms? Well, like in the example of Virtual Servers, for example VM machines on the ESXi server, it's the ESXi that provisions the physical resources of the Physical Server or a Cluster to accommodate the needs of the VM. In the same manner, Network needs to provision the VLANs, required Firewall rules, and adjust the IP routing to "welcome" the new Application. Basically the aim of NV is to solve the Virtualization gap between networking, compute and storage.

Main Concept here is the the NFV, as a natural complement to SDN Architectures. vRouter is a foundation of NVF: You take the routing and implement it as a Virtual Machine called vRouter and put inside the Server (x86 platform), and also implement some of the security, so you get a VM which is a vRouter containing NFVs such as VPN, Firewall and Router.

A very important VLAN-analog concept appears when we're talking about the Network Virtualization of the Data Center, and as you probably assumed - it's a VXLAN (Virtual Extensible LAN). This technology appears to be a direct response to the multi-tenancy requirements, and the resourse separation between the traffic flows of each of the tennants. Don't be afraid of it, and it will be your friend. VXLAN is an overlay protocol, and it's got an encapsulation and decapsulation process. It's basically like a wrap protocol around an Ethernet frame, nothing more then that. It basically adds 50 bytes of overhead when encapsulating the Ethernet Frame in UDP, so instead of 4096 VLANs - we have 16 million segment IDs. Please check out the below video made by Cisco (don´t you just love this guy?) about the VXLAN fundamentals.

Another inevitable concept is the API. APIs allow software developers to write code that provisions the network as an entire entity. Some of these APIs are public, so the big Networking players, such as Cisco, will publish their APIs and provide a detailed documentation about how to integrate with their products. The list of most popular APIs related to SDN can be found here.

The concepts of VXLAN and APIs are so important that I will definitely dedicate a separate post to each of these.

The problem with the SDN is that everyone seems to have their own way of understanding it. Yes, it's related to the concept of Network Virtualization, but it seems to be more "adjustable" to what the company is trying to sell you. You will see "SDN ready" on many products, and recently I've even found a post on Network World that MRV added a special port called ""the SDN port". Just don't let all this confuse you, and form your own definition of SDN (read more here). One thing is for sure - no metter how you define it now, technology changes so fast in this field that in a few months your definition will be utterly different.

CCIE RSv5 Transition Technologies

CCIEv5 started in June, and since my plan is to have the exam prepared for December, I'll first be getting into the New Topics of the Blueprint v5 Lab Curriculum. As you probably know, CCIEv5 is all about virtual equipment with Fast Initial Configuration Reload. If you're a Cisco employee you might take the advantages of IOU, and if not - you always have the GNS3 option. There's no full L2 support on GNS3, so I recommend you to take a deep dive into the following post by INE about the CCIEv5 Hardware.

Since I lost privileges to my old physical rack (I changed the company a few months ago), I'll have to make up my mind soon. I'll probably go with the Virtual Switch, as INE proposed, and sieze the opportunity to broaden my knowledge on the Network Virtualization. In a few years these concepts form a part of Network Engineers everyday life, and you´ve probably noticed that some of my recent posts have been dedicated exclusively to SDN and Network Virtualization technologies.

The exam has changed, but not too much. Here's how it looks now:
Troubleshooting (2h + 30m of Flexible Time)
DIAG (30m)
Configuration (5h30m)

DIAG is the "new guy", and my assumption is it will feel a lot like the written part of CCIE exam, with a bit more details to analyse. I honestly don't like the addition of this new part, because I feel that knowledge of that type should be tested in the theoretical part of the exam, and I think that it might make the candidates lose a bit of focus from really important lab stuff.

I'll be doing a so called CCIE transition posts chain, that will consist of 5 posts, each one dedicated to one of the 5 new topics added to the CCIE R&S curriculum.

1. DMVPN (single hub)

2. Bidirectional Forwarding Detection (BFD)

3. EIGRP (multi-address) Named Mode

4. EIGRP and OSPF convergence and scalability

5. IPsec with pre-shared key

All of these technologies shall be included in my CCIEv5 Script Update [expected release date - August 2nd 2014].

CCIE vs SDN

Most of you who've been following my blog in the past, or even most of you who've stumbled upon it by randomly looking for "some Cisco stuff "on Google, are aware that this blog was originally designed as my personal notebook while moving towards the CCIE certification. It's been a while since I started, and I even had an unsuccessful attempt to become a CCIE a few months ago (April 2014). Yeah, yeah, it made me stronger and all... but I was a bit dissapointed because I got the Troubleshooting part which I considered more complex, and failed the configuration part which I was convinced that I was passing. As I'm getting familiar with the CCIEv5 blueprint and planning the next attempt for December, a single 3 letter acronym keeps challenging my motivation. As you probably guessed, I'm talking about the SDN (Software Defined Networking).

[Update, Nov2014] Got my CCIE number, #45370 :)

If you're a Network Engineer, you would have to had lived in an isolated box if you haven't heard of SDN, ACI, APIC, NSX, OpenFlow, OpenDaylight and so on. Clients keep asking us about it, Vendors keep pushing the "where we stand" presentations on us, Blogs and Networking magazines are simply flooded with the separation of Control and Data plane, and the question that comes to mind is - should I proceed my CCIE preps?

Recently I was assigned an R&D project that involved a current market research and a proposal of a Major Upgrade of Clients entire Data Center Infrastructure (12 Data Centres). The requirement was simple - build us a scalable and elastic SDDC (Software Defined Data Center), while having in mind that we like term "Virtualization" a lot! Now I've been following the SDN Central, Network World, as well as various blogs and events for ever since I've first heard about it. Even so - there were just so many new technologies, acronyms and terms to investigate. And you know what the most interesting thing was? During the investigation, whenever an article I bumped into was more then 6 months old - it was obsolete and inaccurate. I was able to rely only on the articles published within the last few months.

So, who will win an entire SDN race?
I have absolutely no idea. No-one does, and no-one can have it at this point. Cisco has been throwing billions of dollars out of pure fear if you ask me, starting from Insieme acquisition, all the way to ACI architecture with the Cisco APIC "SDN Controller" launch. ACI seems like a pretty decent solution at the moment too, and it makes much more sense to me because some level of control is still left to the Switches. Maybe I feel this way cause I've been in the networking industry in the last 10 years, and viewing an entire Network Infrastructure as a end-to-end dumb tunnel (VMware's view) just doesn't seem feasible.
VMware has a completely different strategy. Martin Casado and Nicira (Network Virtualization company acquired by VMware) have an extremely different approach. Their strategy is - turn the network into a Software and run it over bunch of White Switches. My first reaction is - yeah, right, I'd like to see a Networking professional who tries to sell this to a serious client at the moment. But then again - you never know where the market will move towards. Maybe VMware can make this work! Yes, their idea is a bit... out there, and I can't picture a professional solution where an entire network is seen as a no-brain tunnel, but if Network Equipment Vendors, such as HP and Juniper, join the venture and find the way to "take care" of the NaaS, and if OpenFlow actually blooms into something a bit more decent - who knows what might happen.
On the other side there are hordes of vendors, such as Brocade, HP, Huawei and IBM, doing everything they can to take at least a part of the market Cisco has (almost 70% of Network Equipment out there is currently Cisco). Of course all of them will support and participate OpenFlow and OpenDaylight with everything they have, and support all the possible SDN solutions, in order to eliminate Ciscos' predominance. It's only logical.

Where does that leave us, the Network Engineers?
I guess we're all a bit sceptical about an entire SDN acceptance, it all seems foggy and not yet mature.
- Should we be ready for it?  Yes! By all means we should.
- Should we learn some scripting, Python or something similar? Maybe...
- Should we abandon out Networking careers, and simply switch to the SDN track, or something else? No! Networking professionals just cannot become obsolete, because the programmers simply don't have the TCP/IP, Internet and L2 knowledge. The SDN software will just be a new tool to achieve what we've been doing so far using our precious CLI.

Conclusion
I will most definitely pursue my CCIE adventure. I simply want to be a CCIE. Is that the only reason? Of course not. CCIE simply defines the class of a Networking professional you are. It defines your determination, ambition and knowledge. Yes, I have met many Networking professionals who are not CCIEs, even though their Networking knowledge is deep and simply - impressive.
What's the difference? It's simple... They need more time and a bunch of proving to do in order to convince their clients as well as colleagues that they are good enough to be entrusted with major projects. Sometimes you just don't have the time you need.