Back in my high school days, I took a class in mythology, and one of the stories that really stands out to me is the story of the Sirens. These Sirens were alluring creatures, with amazing voices, and they made beautiful music. They lived on islands, and they would sing out to sailors sailing pass their islands. Upon seeing the beauty of the Sirens and hearing their music, the sailors would steer their ships toward the islands, only to have their ships destroyed by the rocks surrounding the islands.
Today, we use the term Siren call to refer to something that looks appealing but is actually dangerous, and I think that is a great description of brain dumps. You’ve probably heard of these brain dumps, where people take an exam and post online the exact questions they saw on the exam. However, it’s not just individuals posting these questions from their short term memory, there are also companies with collections of actual exam questions that they sell on the Internet....
Studying for your CCNA R/S (200-125) exam? If so, a perusal of the exam topics list can be daunting. Clearly, you’re going to spend a significant amount of time getting at least a passing familiarity with the myriad of topics. However, your focus should not be spread evenly over all topics. Rather, there are some topics that need a disproportionately large amount of study.
That’s the focus of this blog post, identifying 3 of the topics likely to appear multiple times on your 200-125 exam. These topics won’t come as any surprise, but I hope this will be a reminder to expend that extra measure of effort when reviewing “the big 3.” Let’s check out the list:
To be prepared for IP addressing questions on the CCNA R/S exam, you need several skills, including:
For decades, we’ve heard about Cisco’s three-tier network design where we had the following layers: (1) Access, (2) Distribution, and (3) Core. The Access Layer connected to our end devices (e.g. clients and servers). The Distribution Layer redundantly interconnected Access Layer switches, and provided redundant connections to the campus backbone (i.e. the Core Layer). The Core Layer then provided very fast transport between Distribution Layer switches.
However, within today’s data centers, a new topological design has taken over. It’s called a Leaf-and-Spine topology, and in this short blog post, you’re going to learn the basics of how it’s structured.
Imagine a cabinet in a data center, filled with servers. Frequently, there will be a couple of switches at the top of each rack, and, for redundancy, each server in the rack has a connection to both of those switches. You might have heard the term top-of-rack (ToR) used to refer to...
Are you going to Cisco Live US (CLUS) 2017 in Las Vegas? If so, you might want to come check out my session. It's entitled Number Globalization and Localization for CCIE Collaboration Candidates. But, please don't be thrown by the title. Even though it has CCIE in the title, this session can be super valuable to you if you work with Cisco Unified Communications Manager (CUCM) servers, regardless of your certification level.
This video gives you the details of what you'll be learning:
You can check out the session in the CLUS Schedule by clicking HERE.
Hope to see you in Vegas!
It was 1989 when I first laid hands on a Cisco router. Specifically, it was a Cisco AGS+ router. Well, actually, it was called a “brouter,” because it did both bridging (software-based Layer 2 switching) and routing. The version of Cisco IOS it ran was some flavor of 7.x, but at that time, the operating system had not been given the Internetwork Operating System (IOS) name.
Since that time, Cisco has paraded out a variety of additional operating systems, many of which are now defunct. Some of those operating systems came through acquisitions. For example, in the mid-1990s, Cisco started building up their line of Cisco Catalyst switches by acquiring Grand Junction, Kalpana, and Crescendo. Switches coming from these various lineages ran different operating systems. Cisco also came out with different operating systems for their hubs, load balancers, security appliances, unified messaging modules, etc. However, Cisco IOS was long viewed as the defacto Cisco operating system,...
The day-to-day tasks of Cisco network engineers are in the midst of a major industry shift. Specifically, we’re moving away from traditional command line interface (CLI) commands, and moving towards having programs do the work for us. The industry term for this new environment is Software Defined Networking (SDN). Cisco’s SDN product suite is called ACI. As an example, we could write a program to talk with a Cisco APIC controller, which could then send out commands to multiple Cisco devices (e.g. routers and switches).
This change is going to require Cisco engineers to become proficient in programming, and the most common programming language for SDN is the Python programming language. Unfortunately, the challenge of learning a new programming language can be a bit daunting even to seasoned engineers.
Fortunately, this video will break the FUD (Fear, Uncertainty, and Doubt) surrounding Python. Specifically, in this video, you’ll learn:
This blog post wraps up our series on Understanding EIGRP by discussing two final topics:
Let's begin our discussion by considering the EIGRP router ID.
Each EIGRP-speaking router has an associated EIGRP router ID (RID). The RID is a 32-bit value written in dotted decimal format, like an IPv4 address. A router’s EIGRP RID is determined when the EIGRP process starts. Interestingly, EIGRP uses the same steps to RID calculation as does OSPF. The following list identifies these step, in sequential order:
Step 1. Use the configured RID value (using the eigrp router-id rid EIGRP router configuration mode command).
Step 2. If no RID is configured, use the highest IPv4 address on a loopback interface in the up/up state.
Step 3. If no loopback interface is configured with an IPv4 address, use the highest IPv4 address on a non-loopback interface.
Interestingly, while EIGRP requires a router to have a RID, the...
Typically, an EIGRP-speaking router dynamically discovers its neighbors, by sending multicast Hello messages. However, there is an option to statically configure those neighbors, and communicate with them via unicast messages. This is rarely done, but could on rare occasion be useful.
Consider for example a Frame Relay WAN. Imagine that router A has an interface configured with ten Frame Relay permanent virtual circuits (PVCs). At the other end of two of those PVCs resides EIGRP-speaking routers. However, the other eight PVCs do not have an EIGRP-speaking router at the far end. In such a topology, if router A’s WAN interface was participating in EIGRP, then router A would have to replicate its EIGRP Hello message and send a copy out all ten PVCs, resulting in an increased processor burden on router A and increased the bandwidth usage (unnecessarily) on the eight PVCs not connecting to an EIGRP router. This is the type of situation that would benefit from our statically...
It's another one of those buzzwords we're hearing a ton these days, the Internet of Things, or IoT for short.
But what exactly is it, and how's it going to impact us as networking professionals? That's what you'll learn in this new video:
Sometimes, we might want a router interface to participate in an EIGRP routing process (in order to advertise that interface's network) without that interface sending out EIGRP Hello messages. That's what we'll cover in this blog post.
By the way, this is the fourth posting in a series on Understanding EIGRP. If you missed any of the earlier postings, you can check them out here:
Previously, we talked about the network net-id wildcard-mask command issued in EIGRP router configuration mode. This command causes two primary actions: