This video is a sample from our CCNA (200-301) Video Training Series, and it gives us a high-level overview of three configuration management utilities: Puppet, Chef, and Ansible. These are new network programmability topics added to this version of Cisco’s CCNA exam.
It’s interesting that the verb used by the exam blueprint isn’t configure, troubleshoot, or explain, it’s to “recognize the capabilities of” these tools. So there’s no need to have programming knowledge of these tools for the CCNA exam.
Enjoy the training!
Specifically, this week's video considers IOCs, which is short for Indications of Compromise. We look at this from the perspective of Cisco AMP for Endpoints.
Enjoy the training!
This video is a sample from our upcoming CLCOR (350-801) Video Training Series, which is being released February 2021.
In this training video, we'll consider SIP, which is short for Session Initiation Protocol. Specifically, SIP is a standards-based call signaling protocol that can be used to setup and teardown calls between a couple of Cisco IP Phones. We'll consider the messages exchanged during a SIP call setup, and we'll distinguish between SIP Early Offer and Delayed Offer.
Enjoy this training from our CLCOR (350-801) Video Training Series!
Charles has been wrapping up production on the SCOR (350-701) Video Training Series this week, so we thought it’d be fitting to go over one of the topics on the blueprint with you!
In this video, Charles takes a look at the advantages and features of Cisco Stealthwatch. Enjoy the training, and stay tuned for an upcoming product launch in the near future!
As we approach Thanksgiving Day here in the states, I've been reflecting on what I'm thankful for this year. Even though 2020 has been a very unique year, I'm thankful for lots of good things that have happened. Here are just a few examples:
I pray that each of you have a blessed holiday season.
With a grateful heart,
In the previous part of our OSPF series, we examined options for manually filtering routes. As we wrap up our look at advanced OSPF topics, we'll discuss default routes, and compare OSPFv2 with OSPFv3.
We have seen where OSPF can automatically generate a default route when needed. This occurs with some of our special area types. For example, of you configure a totally stubby area, of course a default route is required and OSPF generates this route automatically from the ABR.
In order to increase flexibility with your designs, default routes injected into a normal area can be originated by any OSPF router. To generate a default route, you use the default-information originate command.
This command presents two options:
In our previous blog post, we examined how OSPF can automatically filter routes through the use of special areas and LSA Types. But what about your options for manually filtering routes in OSPF? In this post, we will examine techniques that you can use at various points in the topology.
One simple and effective method of filtering at the ASBR is the use of a distribute list. Here, we define the rules for route identification with an access list, and then reference this access list in the distribute list.
Figure 1 - OSPF Topology
In this example, our Area 1 is configured as a normal, non-backbone area. You can clearly see this when you examine the routing table on ORL.
Note the two prefixes (E2) of 192.168.10.0 and 192.168.20.0. Let’s filter 192.168.10.0 at the ASBR of ATL.
Note how simple this configuration is. Let’s see if it worked by examining the route table of ORL once again:
The configuration worked perfectly and...
Last time, we began our look at advanced OSPF topics with the configuration of backbone and non-backbone areas. In this blog post, we'll look at the creation of more specific area types.
Figure 1 - OSPF Topology
It is time to make our Area 1 from Figure 1 a stubby area. This is a simple configuration change. On each device in the area, we need to set the Area 1 as stub. Here is the configuration in our network:
This will cause a reset of the adjacency (as you might guess). After this change, it is time to check the OSPF route table and the OSPF database on ORL:
Just as we would hope, the routing table is smaller now! There is no longer the detail of the external prefixes from the ASBR. Instead we have a default route automatically generated by the ABR. This default route is needed, of course, because the routers in Area 1 still need to be able to access the remote prefixes (if needed).
Now it is time to examine the OSPF database. It is exactly what we would expect to...