With the complexity of our industry, two things should be obviously necessary. These two things are Network Design and Validation Testing. Design requires identifying the requirements of the business and of dependent systems. This could include things like minimum bandwidth, maximum jitter, convergence time, recovery time, minimal redundancy, etc. It is also important to understand that more rigorous requirements often contribute to cost and operational complexity. Operational complexity creates additional challenges that often erode the very parameters that have been identified as requirements. When this is found true, there are some conversations that need to be had about what is and is not achievable, given the operational and capital budgets–as well as the realistic capabilities of the staff managing the environment.
Validation is also critically important. I posted an article a few weeks ago that illustrated an interesting failure with CAPWAP. Avoiding issues like this require us to first design our network then validate the behavior against the design. Allow me to make a bold statement–If you haven’t designed and validated your network, you DON’T know how it works. Without validation–How do you know that your convergence is subsecond? How do you know that your backup routes work with applications? How do you know that you aren’t introducing unexpected asymmetry that is yielding your IPS even more useless than encryption? The answer is that you don’t know.
You don’t know that the wrong HSRP peer is active, that a switch in some closet is the STP Root, that RSTP portfast is not set up correctly, that LDP Sync was omitted, that NSR/NSF has been overlooked on that VSS pair, or that a bug exists in a key feature since the last upgrade. Maybe you are just that good, but my guess is that none of us are. There are so many things that can lead to unexpected behavior. Therefore, we MUST test against anything that is truly a requirement and part of our Design.
I recently stumbled into what I think is a very interesting failure scenario with a Cisco Wireless solution. This was a traditional controller based solution that leveraged a CAPWAP data and control plane. The symptoms were fairly consistent and strange.
When issues are occurring, all uploads reduce to about 1.5Mb/s
Installing a new AP seems to solve the issue
Issue re-occurs in a few minutes
Issues only occur for one specific site
Wireless is configured consistently across 5 sites
Bonjour and mDNS are discovery mechanisms that generally work effortlessly within a single VLAN. Those attempting to implement these protocols in a multi subnet environment often run into some significant challenges. The typical use of CAPWAP in an enterprise wireless network adds to the segmentation between wired and wireless domains and requires special attention with devices like Applet TVs and Bonjour based printers. In this article, I will address the use case of allowing a wired Apple TV to be seen and used by a wireless client. We will also do some basic filtering to contain those advertisements to a single building.
Nearly eight years ago, I wrote an article about configuring the ASA to permit Traceroute and how to make the device show up in the output. That article is still relevant and gets quite a few hits every day. I wanted to put together a similar How-To article for those using Firepower Threat Defense.
This article examines the configuration required to allow proper traceroute functionality in an FTD environment. The examples shown here leverage Firepower Management Center to manage Firepower Threat Defense. As with any configuration, please assess the security impact and applicability to your environment before implementing.
Before we get started, it is important to understand that there are two basic types of Traceroute implementations. I am using OSX for testing and it defaults to using UDP packets for the test. However, I can also test with ICMP using the -I option. I am already permitting all outbound traffic, so this is not a problem of allowing the UDP or ICMP toward the destination. Continue reading →
A few months back, I wrote an article about my Initial Observation on the Firepower FMC API. Today’s article takes this one step further with a step-to-step guide to connecting Postman to the FMC API. It is worth noting that this is not a directly useful process, but a process that should be expanded upon to achieve any objective that is better served by an API. Use cases might include bulk changes or integration with other security applications.
The Official REST API Guide can be found at the following URL.
A few years ago, I took an SE role covering Higher Education accounts. I quickly realized one of the deficits Cisco has in the CCNA program as it pertains to networks with a certain set of requirements. While the program is jam-packed with great information, there are a few concepts that an administrator may have to deal with that catch them by surprise. Three related topics that aren’t covered in CCNA Routing and Switching are shown below.
This article is meant to serve as a starting point for those who may be very strong with routing and switching but lack the exposure to VRFs, Layer 3 Segmentation, and MPLS. It is a good starting point for new employees that might face this challenge and it will certainly help them gain perspective on these topics. Continue reading →