The debate of what we should be learning seems to be a more frequent topic today. For instance, there’s been a long-standing question for each new networker: after learning a little about routing and switching, does a relative newbie dive deep into route/switch? Move on to learn voice? Or security? Data Center? Or for emerging technologies like SDN, should we learn SDN as defined by the Open Networking Foundation, or ACI, or both? Should we build programming skills to become network programmers, or programming for network automation, or stick with traditional config/verify/troubleshooting skills?
So we can talk to coworkers and discuss/argue about what technologies we should learn… but then we all seem to agree that learning throughout our careers is hugely important. (In fact, the day I was wrapping up this blog post, the Cisco Champion podcast included several people making that very same point, in agreement.) And then we stop talking about learning, because we all agree. We agree that learning is important, and don’t talk about how to learn effectively.
Our long-term career prospects depend in part on learning about existing and emerging technology. But how good are our learning skills? Are we happy with the results? How can we get better at learning?
Today’s post begins a 2-part post that offers a top 4+1 list of answering that last question: how do we get better at learning? Rather than us just agreeing that learning is important, and moving on, let’s treat the process of learning as an important process, and learn how to do it better. Read More »
Tags: #ciscochampion, certification, learning, study
I’ve been a huge fan of Cisco and NetApp’s FlexPod since 2011, when I had the pleasure of working with it for the first time. We had just gotten two brand new UCS Chassis full of B-Series blades, and I was impressed with how quickly I had them up and running. I wired up the UCS Chassis to a Nexus 5000 switch I had in the lab, as well as a NetApp FAS2020, it wasn’t pretty, and it wasn’t in the same rack, but it was still a FlexPod. When I did some firmware updates a couple of weeks later, again, it was simple process. I could have actually scheduled it to run later, which I thought was an extremely cool feature. It took next to no time to have everything revved to current levels (the poor UCS sat in the lab neglected for a few months before I got my hands on it).
FlexPod has come a long way since then, so let’s take a look at some of the hottest Cisco Validated Designs out there today, and a little bit more about what makes a FlexPod a FlexPod Read More »
Tags: #ciscochampion, Cisco UCS, FAS, FlexPod, Nexus 5000
Building an IoT company is a great opportunity to work on things you have never done before. Here is a list of my conclusions with brief anecdotes about the difficulties of building az IoT company.
Choose the size of your funding need wisely
When we started, our pre-seed angel investor suggested to close an angel round by involving other investors. The more money you attract at the beginning, the longer runway you have to develop the product that you believe in without having to take away your focus from value creation. It turned out without having the credibility of using small investments wisely and build traction with it you won’t be given the opportunity to get funded with hundreds/millions of Dollars. Build up your credibility together with your venture. One step at a time. Read More »
Tags: #ciscochampion, internet of things, IoT
Nowadays, there are billions of devices connected to the Internet, and this has led to some advances in the Electronics and Telecommunication technology developments in recent years which resulted in various kinds of very powerful devices with communication and networking capabilities that have attracted the industries to adopt this technology into their daily business to increase their efficiency. Other than the industrial sector, there are other sectors like assisted living services, public services, etc., which have a big demand for Information and Communication Technology developments. Therefore, there is the need for a new paradigm in M2M communication which enables “Things” connectivity to the Global Internet Network. This paradigm is known by the term IoT.
IoT is the network of physical objects or “Things” embedded with electronics, SW, Sensors and connectivity to enable it to achieve value and service by exchanging data with the manufacturer, operator and/or other connected devices through advanced communication protocols without human operation. The technology of IoT has been evolved according to the environment based on information communication technology and social infrastructure, and we need to know the technological evolution of IoT in the future. Read More »
Tags: #ciscochampion, Cloud Computing, Fog computing, grids, internet of things, IoT, smart, smart grids
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