Archive
Category Archives for "PacketU"http://www.packetu.com/
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
- Where to Use a VRF
- VRFing 101, Understing VRF Basics
- VRFing 102, Providing Internet Access With Dynamic PAT
- VRFing 103, Using NAT Virtual Interfaces for Global Reachability
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
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
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.
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.
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