These days, Quality of Service (QoS) can be configured relatively easy. If we’re using the APIC-EM as a network controller to manage our routers and switches, we can simply point and click our way through the EasyQoS utility and have a very robust QoS configuration applied to our devices. Even at the command line interface (CLI) of a router a switch, we could invoke the power of AutoQoS VoIP (to optimize QoS settings for voice traffic, or (just on routers) AutoQoS for the Enterprise (to discover network traffic patterns and create a customized QoS configuration to reflect our network’s specific characteristics).
However, what if you need to make an adjustment to such dynamically generated QoS settings? If you examine the underpinnings of any of these QoS automation tools, you’ll see they all use the same approach to configure most (of not all) of their QoS settings. This approach is called Modular QoS CLI, or MQC for...
The Auto Smartports feature available on Cisco Catalyst switches allows a port to automatically detect that you’ve attached a device it can recognize (e.g. a Cisco IP Phone, wireless access point, video surveillance camera, etc.)
Then, it runs a macro on that port to apply a "best practice configuration," including QoS, STP, and security settings.
This video introduces you to this exciting feature and gives you a configuration demonstration.
Kevin Wallace, CCIEx2 (R/S and Collaboration) #7945
Some of my blog posts (most of them, in fact) focus on teaching you some technical content or offer career advice. But, sometimes, I just need to share a major milestone with you. That’s what I’m doing in this post (actually, a couple of major milestones), and I hope you can (virtually) celebrate with me.
The first milestone is my 3-year anniversary of being in business full-time as Kevin Wallace Training, LLC. Specifically, on Sept. 26, 2014, I walked away from my 14-year position as an instructor for a Cisco Learning Partner (CLP) to run my own business.
During the past three years, I’ve released a ton of training videos. However, I hadn’t actually taught a live online class, allowing me to interact with participants. That all changed this month, which brings us to the second milestone.
Earlier this week (I’m writing this on 9/15/17), I wrapped up my first live-online training class in about three years. I was given the opportunity to...
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:
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:
In our Cisco routing and switching studies, we commonly study routing protocols such as RIP, OSPF, EIGRP, and BGP. However, there's a very scalable, fast converging, link-state routing protocol that often gets overlooked and forgotten. It's Intermediate System to Intermediate System (or IS-IS for short).
IS-IS is primarily found in service provider environments, but even if you're not in the service provider world, you still might run into it at some point during your career. So, I wanted to create a video to take away the fear, uncertainty, and doubt from IS-IS. In this video, we'll look at the basic theory surrounding IS-IS and then go through a simple configuration.
Enjoy the video!
Kevin Wallace, CCIEx2 (R/S and Collaboration) #7945