With the adoption of overlay networks as the standard deployment for multi-tenant network, Layer2 over Layer3 protocols have been the favorite among network engineers. One of the Layer2 over Layer3 (or Layer2 over UDP) protocols adopted by the industry is VXLAN. Now, as with any other overlay network protocol, its scalability is tied into how well it can handle the Broadcast, Unknown unicast and Multicast (BUM). That is where the evolution of VXLAN control plane comes into play.
The standard does not define a “standard” control plane for VXLAN. There are several drafts describing the use of different control planes. The most commonly use VXLAN control plane is multicast. It is implemented and supported by multiple vendors and it is even natively supported in server OS like the Linux Kernel.
This post tries to summarize the three (3) control planes currently supported by some of the Cisco NX-OS/IOS-XR. My focus is more towards the Nexus 7k, Nexus 9k, Nexus 1k and CSR1000v.
Each control plane may have a series of caveats in their own, but those are not covered by this blog entry. Let’s start with some VXLAN definitions:
(1) VXLAN Tunnel Endpoint (VTEP): Map tenants’ end devices to VXLAN segments. Used to perform VXLAN encapsulation/de-encapsulation.
(2) Virtual Network Identifier (VNI): identify a VXLAN segment. It hast up to 224 IDs theoretically giving us 16,777,216 segments. (Valid VNI values are from 4096 to 16777215). Each segment can transport 802.1q-encapsulated packets, theoretically giving us 212 or 4096 VLANs over a single VNI.
(3) Network Virtualization Endpoint or Network Virtualization Edge (NVE): overlay interface configured in Cisco devices to define a VTEP
VXLAN with Multicast Control Plane
Read More »
Tags: #ciscochampion, Cisco Nexus 9000, CSR1000v, Nexus 1000, Nexus 7000, Nexus 9000, VXLAN
In youth-oriented Silicon Valley, it’s risky to mention this, but I’ve been around for a long time. In fact, in theory I could retire! I already moved to a small town in the Pacific Northwest where the cost of living is low, and I could spend my days hiking in the mountains.
But actually I can’t retire. Why? The networking field is too interesting! In addition, modern networking, with its emphasis on design, applications, policies, and users, focuses on the same concepts that have interested me from the beginning. Not only that, but I firmly believe that with today’s network design tools, we are positioned to build networks that are faster, larger, and even more user-friendly than ever. How could I retire when that’s the case?
In the Beginning
I started my career as a software developer. This was long before agile software development became popular, but nonetheless there was a focus on agility and flexibility. The goal was to develop software that could be used in multiple ways to support a broad range of users. The focus was on user behavior, application modeling, systems analysis, and structured design. Read More »
Tags: #ciscochampion, Cisco APIC, Cisco Application Centric Infrastructure, Cisco SDN, Declarative, Network design
The routine goes something like this. First a breach of security occurs somewhere in the enterprise, it could be something as small as a single computer getting infected or it could be a massive data loss. It seems like that’s a wide range of events, but often the reaction in an enterprise is the same. The IT executives have a meeting to determine fault and then the analysts and engineers are given the task of making sure that that particular incident never happens again. The analysts and engineers then reply with budget requests for new software and hardware from their favorite vendors. Unfortunately the end result is generally that money is spent and security is only moderately improved, if at all.
In the midst of reacting, everyone forgets that technology doesn’t configure itself and that the weakest link are the people. Instead of ramming in the latest and greatest in technology, we should be leading our company to review, create (if necessary) and rewrite our security policies. Without a policy, security tools are like unguided missiles that we hope hit their target. Read More »
Tags: #ciscochampion, ASA, Cisco ASA with FirePOWER Services, Cisco Security
When I started with my first Cisco router back in 1995, I never would have imagined I would someday be the technology lead for an ice arena of an NHL team. I also would never have predicted the impact that having a Cisco certification would have on being recruited to that position.
Most of my career up until now was spent working in the small and medium business space, primarily on ISP and telecom space working with voice and networks with some software and infrastructure design in the middle. Cisco was a large part of everything that I did from routing and switching to voice over frame relay followed by voice over IP, with a large emphasis on small bandwidth efficiency and signalling. I’m even the lead inventor on an issued patent relating to intelligent rerouting of fax traffic on VoIP systems.
I never thought much about certifications. I have a BA in Economics which has served me well as a business owner and largely found all my work via word of mouth. There were not a lot of people who understood VoIP payload and signalling tuning, starting from the MC3810 and up through the as5300/as5800 series. This was primarily in international carrier / wholesale VoIP traffic and engineering.
As VoIP became more of a commodity good and the cost of equipment came down, this market dried up. In hindsight, I should have paid more attention to Cisco exiting that market, which proved to be a good decision. As my clients and partners moved on to other ventures and I was forced to begin prospecting.
Suddenly, here I was with 30 years since I’d written my first program and roughly 20 years of internet and Cisco experience and I was struggling. I had a lot of experience, but didn’t have a portfolio of work that included any big names, mostly small businesses that no one had heard of. I needed a way to give new clients the confidence to call me. I knew that once I started the conversation, I could close the deal. Before that, however, I needed to actually get that call or email. Read More »
Tags: #ciscochampion, CCNP, certification, Cisco Certification
If you are a technology professional, then chances are that you are aware (maybe to the point of annoyance) that everything is getting defined in software these days. We have Software-Defined Networking (SDN), Software-Defined Data Center (SDDC), Software-Defined Storage (SDS), and the list goes on and on. Software defining anything has become such a powerful trend that we now have a generally accepted name and acronym for just that: “Software-Defined Anything” or SDx for short.
Despite the widespread nature of the trend, Software-Defined Contact Center (SDCC) is nowhere to be found amongst the Software-Defined goodness that floods our social media feeds on a daily basis. Software-Defined Contact Center is so absent from the online world that if you search Google for the term you get only articles that reference Software-Defined Data Center, seemly because 3 out of the 4 words are common to both. If you search for the #SDCC hash tag on Twitter you will find yourself at the official account of the San Diego Comic Con. This raises the question, why isn’t SDCC “a thing?” This question is particularly relevant since Cisco’s Intelligent Contact Management (ICM) has been allowing us to build Software-Defined Contact Centers since the late 1990s. Let’s take a look at how ICM delivers on the Software-Defined paradigm for Contact Centers. Read More »
Tags: #ciscochampion, Cisco SDN, ICM, ISDN, IVR, PBX, SDN