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
Posted in How-To
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.
Firepower REST API Quick Start Guide
It is also worth mentioning that the online API documentation can be found at https://<FMC-IP>/api-explorer on the FMC installation.
The general flow of the process we will be following is:
- Connect to FMC using basic authentication
- View the response to obtain the X-auth-access-token and DOMAIN-UUID
- Leverage the X-auth-access-token and DOMAIN-UUID in a request for access control policies
- Leverage the token, domain and policy ID to obtain a list of rules in that policy
- Leverage the token, domain, policy ID and rule ID to obtain rule details
Throughout this process, we will not store any variables and the process will be completely manual for comprehensive understanding. We will leverage Postman as a REST client. Continue reading
Posted in How-To
Tagged api, firepower
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
Posted in Career
Tagged mpls, vrf
This is the final article in the MPLS Intro Series and will quickly mention the need for route reflectors. This need is driven by the iBGP requirement for a full mesh of peers. This means that a network with only 4 PE nodes would have 6 iBGP peering sessions. This is calculated as n(n-1)/2 where n is the number of PE nodes required for a given topology.
As the scale grows, the need for a centralized peering point becomes obvious. For example, a network with 10 PE nodes would have 45 iBGP sessions to meet the full mesh requirement. Route reflectors overcome this rule by becoming a central point that can advertise routes between iBGP “route reflector clients”. The diagram below actually has more peering sessions than the one above (without RR). However, as a network continues to grow, the full mesh becomes quite challenging. Continue reading
Posted in Design
In our last article, we configured and tested a basic VPNv4 configuration. In this article, we will do a hop by hop analysis of each device and look at a packet capture for a couple of the steps in the label switched path. We are using the exact same topology and router names. For the example, I have shut down the connection between P4 and PE2 so no load balancing will occur and we have a deterministic path to analyze.
For the analysis, we will examine the path from CE_Site_1 to 18.104.22.168 at CE_Site_2. For each device, we want to determine the egress interface, the next hop and any MPLS labels that should be present. Continue reading
Posted in Design
In the previous article, we took a look at building a simple label switched path (LSP) through an MPLS network. This article takes the configuration a step further and leverages multiple labels to connect and isolate VRFs over an MPLS core. This is known as MPLS VPNv4. My goal is to introduce a method to bring together VRF segmentation concepts and provide a framework for a scalable deployment.
Before we get started, I am going to rename the routers once again based on their target function. An LER in a VPNv4 configuration is known as a PE node. An LSR router is known as a P node. I am also introducing CE (customer edge) nodes into the topology.
Desired End State
In this example, we will allow CE_Site_1 to communicate with CE_Site_2. Likewise, we want CE_Site_3 to communicate with CE_Site_4.
- P Router – provider router, is considered transit in a label switched path, the term is often used interchangeably with LSR
- PE Router – provider edge router and sits on the provider side of the provider/customer interconnection. Has most of the intelligence and configuration for an LSP and allows a scale-out architecture. The term PE is more common but may be used interchangeably with LER
- CE Router – customer edge router, is the router that sits on the customer side of the provider/customer interconnection
- LDP – Label Distribution Protocol – Establishes adjacencies and exchanges label mapping information between MPLS nodes
- PHP – Penultimate Hop Popping, removing (pop operation) an MPLS label at the next to last hop
Posted in Design