Segmenting Layer 3 Networks with VRFs

I am creating a multi-part series that focuses on Layer 3 network segmentation. This post serves as a landing point and aggregation place for these topics. As the series is built out, the individual links will be available below.

Articles in this Series

The basic topology is shown below. Each article will consist of the configuration information and relevant validation. This should serve as a very good starting point for anyone struggling with building out a common network with strict security zones requiring areas of isolation. Continue reading

Posted in Uncategorized | Tagged , | 6 Comments

APIC-EM Data Export

I was at a Cisco DNA customer event on Thursday. Someone in the audience asked a very good question. Basically they wanted to know if there was a way to extrapolate data from the APIC-EM network management tool. At first glance it didn’t seem to be something that was available in the UI. One of the Cisco representatives quickly and correctly stated that it APIC-EM to Excelis all available from the API.

My initial thought was that this was a product weakness. Why can’t we just manually extract this stuff to a CSV and import it wherever we want to? Whether due to intentional omission or strategic direction, an API first approach is better. It is better because it allows systems to be glued together and more of our mindless tasks to be automated. So the counter argument to that really revolves around use cases, initial effort and skills gaps. The examples I’m about to provide should help alleviate some of those concerns.

TL;DR — Looking to get APIC-EM data into an Excel spreadsheet? Python can easily grab Host and Device Data and provide it in a format that is easily consumable such as Text, Tab, CSV or other format of choice.

Continue reading

Posted in Uncategorized | Comments Off on APIC-EM Data Export

ASA Pro Tip — A Better Prompt

The Cisco ASA FW has a simple and robust failover mechanism. It works so well that sometimes an administrator may not realize that the load has moved from the primary device to the secondary device. When connecting to the IP address, the primary IP address for the interface follows the active unit. So it is even possible to be logged in to a different Firewall than the administrator thinks they are in.

This can easily be determined by doing a show failover.  In the output, it is easy to see if the unit is the Primary or Secondary (configured state) and Active or Standby (operational state). Since the ASA Failover is not preemptive, any glitch moving the load to standby will result in the load remaining there (unless there is a subsequent failure or manual failback).

Given the fact that I am a huge fan of situational awareness, I like to reflect the state in the CLI prompt. This is a simple configuration change.

asav-1# 
asav-1# conf t
asav-1(config)# prompt hostname priority state 
asav-1/pri/act(config)# exit
asav-1/pri/act# 

Continue reading

Posted in Uncategorized | 2 Comments

ASA Active/Standby with BDI/BVI

I see a lot of ASA designs and they are typically flanked with switches. One of the reasons for this is that the failover requirements typically dictate that the devices to be layer 2 adjacent in each security zone. There is obviously the requirement to be L3 directly connected to their next hop. The result of this requirement that an ASA can’t typically be directly connected directly to an L3 only device and it is often the case that a switch is sandwiched between the FW and the next L3 device.

This article is meant to outline a possible work around with IOS and IOS-XE based routers to provide the L2 two adjacency using inherit L2 features. Readers may use these sample configurations to build out there own labs and more fully validate the applicability the their environment. Continue reading

Posted in Uncategorized | 8 Comments

Quickly Adding an NMS to VIRL

I’ve spent the last few days experimenting with APIC-EM and the path trace capabilities. My lab environment is currently leveraging VIRL (Virtual Internet Routing LAB). Since it wasn’t obvious how to integrate APIC-EM with the lab platform, I wanted to share my configuration.

TL;DR–When building the topology, click the background and view the properties for the Topology. Change the Management Network to “Shared flat network”. This will put the all of the devices ‘Mgmt-intf’ vrf on the ‘flat’ (172.16.1.0/24 by default) network when the topology is built. 

When I started this process, I really didn’t realize how easy it could be. I actually tried to leverage a manual connection to L2 External (FLAT) to do the management in-band for the topology. This is certainly possible, but there is a much easier way. As most VIRL users have noticed, there is a management IP address that gets assigned to each device. There is a simple configuration change that will allow that address to be one from the ‘FLAT’ pool and connected externally to the ‘L2 External (FLAT)’ network.

flatmgmt

My configuration 

Continue reading

Posted in Uncategorized | Comments Off on Quickly Adding an NMS to VIRL

A Broken Process Placing Consumers at Risk

Below is a chat session I had with Pearson Vue several months ago as I attempted to schedule a recertification exam. Apparently, I have two accounts with them and that prevents next day test scheduling. To put it mildly, I don’t think they adequately explain how they could possibly guarantee non-disclosure of data with email as a transport. Moreover, this seems to indicate a serious disconnect between security and business operations.

Screen Shot 2016-04-07 at 2.00.18 PM

Image Link – for FULL Size View

Continue reading

Posted in Uncategorized | Comments Off on A Broken Process Placing Consumers at Risk

APIC-EM Path Trace Examples – Overlay Networks

Since seeing the APIC-EM Path Trace demo for the first time and seeing how it represents CAPWAP, I’ve been curious how well it deals with other types of overlay/underlay networking. This article is a brief synopsis of that testing and provides some visuals around what was produced with this free management tool.

TL;DR–APIC-EM adds value to most network path traces and typically represents what it knows. The single exception is with MPLS VPNv4. If the MPLS PE nodes are pulled into the device inventory, path trace has a total lack of understanding around the recursive lookup into the global vrf that is required for VPNv4 functionality.

CAPWAP Representation — The Gold Standard

I wanted to start out by showing what an ideal representation of an overlay network would be for a tool like this. Path Trace understands AND clearly represents both the underlay and the overlay network for traffic flowing through a CAPWAP tunnel. The image below shows the extent of the tunnel (darker gray) and the physical components that are responsible for delivery (both through the tunnel and outside of the tunnel).

pathtrace-capwap

Continue reading

Posted in Uncategorized | 1 Comment

Voice Gateway and Voice VRF – Caveats

Many networks leverage what is known as a VRF. These are used for traffic isolation and create separate routing instances within a router. It is important that vrf awareness is confirmed for any service (DHCP, Voice GW, etc) being locally provided for a given point in the network. One use case for such a configuration might be for voice isolation with or without MPLS. In the case that a router is providing voice gateway functionality (i.e. FXO/FXS to VOIP), the voice functions must understand the VRF construct in order to properly fulfill the role.

TL;DR–This configuration sometimes does not behave as expected and, in my experience, may require a reboot after following the documented procedure.

The configuration for VRF-Aware H.323 and SIP for Voice Gateways can be found at the URL below.

http://www.cisco.com/c/en/us/td/docs/ios/12_4t/12_4t15/stork.html

Notice that it makes reference to the fact that the services need to be restarted–

To configure a voice VRF, you must shut down voice services on the gateway, assign a previously defined VPN VRF to the VoIP SPI, and then restart voice services.

Continue reading

Posted in Uncategorized | Tagged | 5 Comments

ACL Trace in APIC EM

I wanted to take just a moment to share the output of an APIC-EM ACL Trace (option in Path Trace). For this example, I have built out the topology below.

pathtracetopology

The applicable configuration for CSR1000v-2 is as follows– Continue reading

Posted in Uncategorized | Comments Off on ACL Trace in APIC EM

FLAT Networks in VIRL Require Promiscuous Mode

So I’m sure this is in the documentation somewhere. But for anyone else out there who is getting inconsistent results with FLAT interfaces in VIRL, Promiscuous Mode support in ESXi seems to be a requirement. Definitely something to check…

promiscuous

Posted in Uncategorized | Comments Off on FLAT Networks in VIRL Require Promiscuous Mode

Connecting VIRL to the Outside World

I’ve been leveraging VIRL for some time to build and test self-contained labs. I’ve always known that there was some ability to connect to the world outside of this environment. Recently, I decided to configure this functionality and I wanted to take just a moment to share what I found.

First and foremost, this isn’t anything difficult or time consuming. So if you have a need to leverage physical devices with your VIRL deployment, don’t hesitate before building it out.

There are two mechanisms for outside connectivity. The first mechanism is called SNAT. This method basically builds static NAT in and out of the environment. I get how this could be beneficial, but I would typically prefer to keep any NAT configuration contained to an environment that I am very familiar with (possibly an ASA or IOS instance outside the lab when an additional NAT layer is required).

The second method, and configuration we will be testing is called FLAT. In this configuration, VIRL connects a L2 broadcast domain between a lab device and an Ethernet interface. In my example I am running the VIRL components in a VM environment on ESXi. So this is a virtual interface that needs to be mapped through the VMWare vSwitch.

To test this functionality, I created the following topology.

virl_flat

From a VIRL perspective, there are a couple of things to be aware of. The default configuration would have VIRL owning the subnet and the external default GW existing at 172.16.1.1. Continue reading

Posted in Uncategorized | 5 Comments

Hairpinning traffic through ASA with State Bypass

Several years ago I wrote an article about the Woes of Using an ASA as a Default Gateway. I have received a lot of feedback about this post and recently had a request for an update around ASA > 8.3. When building this scenario out with current ASA code, I found that the base NAT configuration (internet only PAT) had no bearing on the hairpin configuration. As expected, I found the same challenge around state bypass. I wanted to share a current post that demonstrates the challenges and solutions when traffic is bounced off the inside interface of the ASA.

ASA Hairping

The requirements of the configuration are as follows–

  • TestHost must be able to Telnet and Ping to Internet and PartnerHost
  • The inside interface of asav-1 must be the default gateway for TestHost
  • asav-1 is doing PAT for Internet destined traffic
  • PartnerRTR and ParnterHost have been preconfigured as shown above

The following are the base configurations for all of the devices. The configuration of asav-1 does not seem to allow communication from TestHost to PartnerHost (100.1.1.0/24 network). Continue reading

Posted in Uncategorized | 3 Comments