Paul Stewart, CCIE 26009 (Security), Author at NetworkingNexus.net

Paul Stewart, CCIE 26009 (Security)

Author Archives: Paul Stewart, CCIE 26009 (Security)

What Content is Missing?

Prior to my current job, I enjoyed the time I invested in the community. I spent quite a bit of time on The Cisco Learning Network helping those that were early in career. I also blogged here regularly (typically weekly) and spent time in the Twitterverse and on Slack. From this perspective, taking a job with a vendor was more different than I expected. It was like someone flipped a switch and I was completely spent at the end of each and every day.

On a few occasions, I have tried to get back what I would have previously considered some level of normalcy with regards to the community. I have decided that this year is my year to make some major changes. I must do a better job prioritizing things I care about and realize that some [read many] things just aren’t going to get done. That is one thing I’ve learned over the past few years. Even though I have always felt that my workload was significant, there is nothing like having a job in which you can only get a small portion of the overall work completed. It just doesn’t feel good.

The community and the relationships Continue reading

Why I Bought A Meraki Camera

I recently purchased a Meraki MV 72 and wanted to share some of the logic behind why I did this. Having 4 other camera ecosystems in “production” at my home, this decision to add number 5 may defy logic for many. My thoughts around this particular investment were more about my personal learning than about function.

To provide a little background, I have a combination of various consumer and prosumer type cameras that vary in form and functionality. Every single brand (and ecosystem), while covering some functions very well, seem to leave a little to be desired. Hence the reason to buy a Meraki MV.

No–I do not expect the Meraki solution to be a perfect solution. Actually, since it is built around business use cases, it might not be as good at somethings that I find very useful. However, there is an API that I wanted to experiment with and solidify my knowledge of how I might build and extend my own ecosystem.

The deeper function of the Meraki MV API is included with MV Sense which is an add-on. Fortunately, every MV Sense organization with capable cameras comes with 10 free licenses. This requires the new generation of Continue reading

Connecting ASA to Umbrella SIG with PBR

This article explores the specific configuration of Cisco ASA when using it to establish a tunnel for Umbrella SIG. The first question many may have is, “What exactly is SIG?” The answer to that is quite simple–SIG is an acronym for Secure Internet Gateway and in the Umbrella implementation it is basically a cloud-delivered firewall. In other words, the common Cisco Umbrella Dashboard can apply a policy to traffic delivered through the service by a tunneled connection to an on-premises network device. Also, in other words, Umbrella isn’t just for DNS.

The first thing to note is that this is very much a simple, stateful, cloud firewall for outbound traffic. Policy can be applied to one or more tunnels and a tunnel represents a connection back to a device. So this is a way that a network administrator can apply and maintain outbound policy across a large distributed network with very little ongoing effort in terms of changes. The current iteration of Umbrella SIG is outbound only. If the requirements include public-facing services, there is still a need for doing that in a traditional way using traditional mechanism (NAT, ACL, etc) alongside this configuration.

I started Continue reading

Network Design and Validation: IT Matters

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? Continue reading

Failure Analysis: An Interesting way to Break CAPWAP

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.

Symptoms:

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
RF is not an issue

Topology:

When I got involved with this, a few people had reviewed the configuration and TAC had been involved for some time. While on-site, I took a look at RF and channel utilization (expecting to find it to be ugly since I knew it was heavily dependent on 2.4Ghz). My first order of business was to spin up a test AP in its own group and advertise a test SSID on a 5Ghz channel. Upon doing so, both iPerf and Speedtest were >50Mb/s. My initial thought was that the density needed to be increased and the radios tweaked to get more clients on 5Ghz. However, a few minutes into my testing–my upload also Continue reading

Cisco WLC for Wired to Wireless mDNS and Bonjour

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.

The Starting Topology

The Scenario

Operating with a baseline configuration, users on the BigU SSID are complaining that they cannot access the Apple TV in BLDG – 3. The first task is to make that device available to those users. While the underlying infrastructure is irrelevant to this configuration method, it is MPLS and cannot be changed in our process. All APs are running in LOCAL mode. This mode creates a compulsory CAPWAP tunnel for the data plane through the controller. In the above diagram, VLAN 110 is trunked out of the controller on to the network in Continue reading

Traceroute through Firepower Threat Defense

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.

Both types of traceroute depend on sending packets with an incrementing TTL field. This is the field that each router decreases as the packet is forwarded. Any router decreasing this to zero should drop the Continue reading

Connecting Postman to Firepower Management Center API

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. Continue reading

MPLS and VRFs – Filling the Gaps

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.

Introduction to VRFs

Segmenting Layer 3 Networks with VRFs

MPLS Intro Series – Route Reflectors

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.

This is the extent of what I really wanted to cover in this introductory level article and this article concludes the MPLS Intro Series. If you want to learn more about VPNv4 and route reflectors, you can check out this video below.

LabMinutes# SP0015 – Cisco MPLS VPN with BGP Route Reflector (Part 1)

Disclaimer: Continue reading

MPLS Intro Series – VPNv4 Packet Walk

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 20.2.2.2 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.

CE_Site_1 – forwarding a packet to destination 20.2.2.2

CE_Site_1#show ip cef 20.2.2.2
0.0.0.0/0
  nexthop 10.1.1.1 GigabitEthernet2

CE_Site_1 is using the default route with a next-hop of 10.1.1.1

PE1 – receive a packet on Gi4 (vrf RED), forwarding for destination 20.2.2.2

//based on physical topology, we know this will arrive on Gi4 of PE1
PE1#show vrf brief
  Name                             Default RD            Protocols   Interfaces
  BLUE                             110:210               ipv4        Gi5
  Mgmt-intf                                      Continue reading

MPLS Intro Series – Introduction to VPNv4

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.

Terms

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 Continue reading

MPLS Intro Series – Understanding a Simple LSP

In the previous article, we created an interesting situation with an iBGP configuration. In that example, we made Edge2 aware of a route via BGP that the intermediary hops would not see. In this article, we will fix this problem using MPLS and label switching. Before getting started, I feel compelled to rename these routers based on their target role in an MPLS our network.

Terms

MPLS – multiprotocol label switching – using labels or tags to forward packets over a network (as opposed to traditional destination based routing)
LSR – Label switch router (transit router), aka P router, switches labels
LER – Label edge router or Edge LSR, often called a PE router, may push (impose) labels
LSP – Label Switched Path
Push – insert/impose a lable
Swap – change a label
Pop – remove a label

As we left it in our previous configuration, the router on the right sees a route to 1.0.1.1 via BGP but it cannot reach that destination. It is worth mentioning that I disabled BGP sync (following the last example I shared in the previous article).

LER2#show ip route | inc  1.0.1.1
B        1.0.1.1  Continue reading

MPLS Intro Series – Destination Routing

Yes, we are going to talk about destination routing. I know it sounds boring and archaic, and it is. But it is also necessary to contrast against another topic that I intend to introduce. As I scour PacketU, I see a substantial number of page views on articles about segmentation and VRFs. One thing I often tell my customers is that once a VRF-lite implementation reaches a certain scale, the configuration can become unwieldy.

This article is a first in a series where we will discuss MPLS. This technology enables VPNv4 and is a common method of networking. MPLS can connect VRFs without compromising their segmentation characteristics. In this first article, we are going to examine traditional destination-based routing. This is meant to nail down some of the typical behavior of an IPv4 routed network. These characteristics will not go away entirely, but it is important to understand how routing changes as we introduce label switching concepts.

Throughout this series, we will use a common topology. In later articles, we will expand as necessary to introduce the relevant topics.

To illustrate a point, I have pre-configured OSPF on all links and loopback 0 of all routers. In a minute, I will bring Continue reading

MPLS Intro Series – Customer Connection with BGP

In the last article, we performed a packet walk of a simple VPNv4 network. This article will expand our deployment by allowing the CE_Sites to advertise their own routes via BGP. For this configuration, we will use some overlapping and some unique private AS numbers.

One thing that must be considered is whether or not the same BGP AS is used throughout a given VRF. For example, if we use 64512 at both CE_Site_1 and CE_Site_2 the BGP routes will be dropped as they are advertised toward the customer site. This is demonstrated by doing a simple configuration to advertise 1.1.1.1 from CE_Site_1.

CE_Site_1 BGP Configuration

interface Loopback0
 description Loopback
 ip address 1.1.1.1 255.255.255.255
!
router bgp 64512
 bgp log-neighbor-changes
 network 1.1.1.1 mask 255.255.255.255
 neighbor 10.1.1.1 remote-as 1

PE1 vrf RED – BGP Configuration and Verification (success)

router bgp 1
!
 no bgp default ipv4-unicast
 neighbor 20.20.20.20 remote-as 1
 neighbor 20.20.20.20 update-source Loopback0
!
 address-family vpnv4
  neighbor 20.20.20.20 activate
  neighbor 20.20.20.20 send-community both
 exit-address-family
!
 address-family ipv4 vrf RED
  redistribute connected
  neighbor 10.1. Continue reading

Redirecting DNS Requests to Umbrella with ASA

As networks begin leveraging intelligent DNS products, there is often a need to do some magic at the Internet edge to redirect to the target provider. Some products actually have this capability embedded. Even though the ASA doesn’t specifically have a defined configuration to do this, we can achieve the same outcome with a few simple NAT rules.

An initial thought would be to build a NAT policy as follows

//define the objects
object network obj_any
 subnet 0.0.0.0 0.0.0.0
object network Umbrella1
 host 208.67.220.220
object network Umbrella2
 host 208.67.222.222
object service UDP-53
 service udp destination eq domain

//define the nat rules
nat (any,outside) source dynamic any interface destination static obj_any Umbrella1 service UDP-53 UDP-53
nat (any,outside) source dynamic any interface destination static obj_any Umbrella2 service UDP-53 UDP-53

This will sort of work. However, there are two words of caution I would share with this approach. First, DNS sometimes leverages TCP. Second, the last NAT rule will never be used. In this case, even requests to 208.67.222.222 would match the first rule and be re-written to the destination 208.67.220.220.

My recommendation would be Continue reading

Redirecting DNS Requests to Umbrella with ASA

An initial thought would be to build a NAT policy as follows

//define the objects
object network obj_any
 subnet 0.0.0.0 0.0.0.0
object network Umbrella1
 host 208.67.220.220
object network Umbrella2
 host 208.67.222.222
object service UDP-53
 service udp destination eq domain

//define the nat rules
nat (any,outside) source dynamic any interface destination static obj_any Umbrella1 service UDP-53 UDP-53
nat (any,outside) source dynamic any interface destination static obj_any Umbrella2 service UDP-53 UDP-53

My recommendation would be Continue reading

Comments on Vendor Optics – Listen Here

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.
.

Disclaimer: This article includes the independent thoughts, opinions, commentary or technical detail of Paul Stewart. This ~~may or may~~ does not reflect the position of past, present or future employers.

Readers of this article may also enjoy:

Comments on Vendor Optics – Listen Here

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.
.

Readers of this article may also enjoy:

Redirecting DNS Requests to Umbrella with FTD

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 – 208.67.220.220
Umbrella2 – 208.67.222.222

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).

We will need four rules that Continue reading

1 2 3 … 9 Next »