I recently listened to Packet Pushers show 395 recently. It is a great discussion on optical networking. One thing I wanted to make everyone aware of was a series of comments on the varying quality of optics and some justification around the premium prices often found on vendor branded optics. While the entire episode is worth a listen, the discussion around vendor optics begins at about 35:20 into the recording.
I work for a vendor and it is doubtful that people would view my opinion as unbiased. I encourage everyone to take a listen below and form their own opinions.
If you are a tech guy or girl, the Packet Pushers Podcast is a perfect addition to the podcatcher. Continue reading
A few days ago I shared an article that described redirecting DNS requests with ASA. A good use case for this might be if an organization is using Cisco Umbrella but there is no way to get every host is pointed toward the correct DNS server(s) in a timely manner. In that case, a configuration of destination NAT in the ASA can force those misconfigured clients to use one of the OpenDNS addresses.
This article is very similar, but we will share a method for doing this with Firepower Threat Defence. The concept is the same but all configuration is done in Firepower Management Console. Before starting on the NAT configuration, it is important to configure the following network objects (Objects, Object Management, Network).
- obj_any – 0.0.0.0/0
- Umbrella1 – 22.214.171.124
- Umbrella2 – 126.96.36.199
It is also important to confirm the existence of two port objects (Objects, Object Management, Network).
- DNS_over_TCP – TCP Port 53
- DNS_over_UDP – UDP Port 53
Most of the configuration will be done on the NAT policy for the device we are managing (Device, NAT, select edit for the appropriate NAT policy). Continue reading
Posted in How-To
A typical Firepower deployment consists of a management component and a managed device. The management component is known as Firepower Management Center (FMC). The managed device is the NGIPS or NGFW itself and would be leveraging the Firepower or the Firepower Threat Defense (FTD) operating system. Both layers of the topology include provisions for redundant deployments. Firepower Management Center is available in a two-node HA configuration. Firepower Threat Defense, the NGFW managed device, can be either HA or clustered.
One question that often comes up is, “What happens when FMC goes offline?” The general response is traffic continues to flow but the managed device cannot be managed. While this is not a good position to be in, it does provide an opportunity to assess the impact of waiting for a maintenance window (or a replacement).
- Firepower continues to pass traffic when FMC is offline
- Events captured on the Firepower device will be passed to the FMC when it is available
- Event Storage on the managed device is finite, events may be lost during an extended outage
- Malware Cloud Lookups/Block functionality depends on FMC, plan HA and File Policy accordingly
- Firepower managed device cannot be managed until FMC is available
Posted in Design
Very early in our careers, we learn about physical and logical network segmentation. Generally speaking, that understanding comes in the form represented by the diagrams below.
Depending on the work environment of an individual, it may take some time before they are exposed to the methods that provide segmentation to routed parts of the network. Looking at the diagram above, let’s think about what is being accomplished in each example. The physical segmentation provides full isolation between the two hosts. This article examines the construct used to extend segmentation into a routed network. We will not get into the configuration details but will share some links to additional content that can provide practical guidance on the configuration. Continue reading
Posted in Design
In conversations I often hear people using the word “mutable”. Typically it would be something similar to the following.
The IP TTL is a mutable field and decreases as it traverses a router.
If we look up the word “mutable” we find that it is something that is likely to change.
So the IP TTL is a great example of a mutable field. That value is expected to decrease at each hop throughout the network.
By contrast, IP Source Address, Destination Address, and Protocol would be immutable because it is not normal for those to change. They should stay constant from source to destination.
I know someone might consider something like NAT or PAT to change some of these attributes. While that is true, I still would not consider those mutable fields.
As I mentioned in a previous post, I have been studying the materials for the Cisco CCDE. One thing that has come up only a time or two is that of MTU. MTU, or maximum transmission unit, is the maximum size a chunk of data can be for a given interface. In this article, we are speaking specifically of IP MTU and this is an important distinction that I will clarify later. Network design should incorporate a clear understanding of MTU challenges and operators need to understand what to look for when it is not properly built and configured.
A simplistic example of a problematic design is when there is a link with a smaller MTU somewhere between two endpoints capable of creating larger packets (see the image below). While this environment may work fine, understanding the interaction required between the hosts and the network devices is very important to network design.
A few years ago I wrote an article that outlined some of the behavior that can be witnessed when there are MTU discovery issues. Let’s quickly recount what path MTU discovery (PMTU-D) is, how it works, how it fails and some logic around appropriate design. Continue reading