The folks at QA Cafe premiered their impressive (and free) online CloudShark service in the summer of 2010. (If this is the first you've heard of it, stop reading now and go have a look.) Just recently they released a Wireshark plugin to make uploading capture files to the service even more convenient.

Installation

To install the plugin, you'll need a version of Wireshark built with Lua scripting support. See Help > About to check for Lua support in your version (look for "with Lua" in the "Compiled" paragraph).

The plugin is available here for Windows, Mac, and Linux. The simple installation procedure for the Linux version is below. Consult the user guide for additional support.

stretch@Sandbox ~/cloudshark-1.0-136 $ ./install-unix
Starting installation of CloudShark plugin for WireShark

Plugin will be installed into /home/stretch/.wireshark/plugins/cloudshark
Installing default plugin configuration file.
The CloudShark Plugin for Wireshark is now installed.
Please restart Wireshark.

Visit http://appliance.cloudshark.org for additional help

A common network implementation for branch offices and other small sites belonging to a larger entity is to have two WAN connections: One is an MPLS or otherwise private connection to the corporate network, and the other is an Internet circuit (often some flavor of broadband) which carries public Internet traffic as well as VPN tunnels which serve as a backup to the private WAN circuit. Typically, the WAN connection requires dynamic routing capability (e.g. BGP) but few security mechanisms given that it merely extends a private network. Conversely, the Internet connection requires strong policy enforcement but no dynamic routing; a default route toward the Internet generally suffices.

Some organizations thus opt to deploy a standalone device to handle each connection at a branch office. The MPLS connection terminates to a branch-level router which supports BGP and offers flexible physical interface options. The Internet connection is typically an Ethernet hand-off which terminates to a low-end firewall. Both the router and the firewall are then typically interfaced with the internal LAN through one or more layer three switches running an IGP. This design is certainly functional and very flexible, however the initial cost of deploying three relatively expensive infrastructure devices in this manner can be prohibitive.

The solution we'll look at today is to move the firewall functionality into the router, so that both circuits terminate into the same device. This removes the requirement for a standalone firewall and the layer three switch, as one device performs all routing for the site. To support security policy enforcement, we'll use Cisco IOS' zone-based firewall feature. Note: The zone-based firewall feature requires a security license and relatively recent code to function properly. IOS 15.0(1)M7 was used in the lab for this article.

Assigning Security Zones

A security zone is a group of routed interfaces which are intended to be treated similarly from a security perspective. For example, if you have two redundant Internet connections from an edge router, both could be placed into a shared "untrusted" zone: It is irrelevant from a security perspective which is the primary connection and which is for failover. A connection into the internal network, however, would be assigned to a separate, trusted zone. Additional zones can also be created with levels of trust which might fall in between the two; for example, a guest wireless network or corporate extranet.

The topology below illustrates a design applicable to what was discussed above, employing three distinct security zones comprising five logical connections.

The three zones are:

• Trusted - MPLS and internal LAN connections
• Guest - Guest wireless
• Internet - Internet connection

The following are a few tips I've learned to make working with connectors in Visio a little smoother. Feel free to contribute your own in the comments.

Set the Line Jump Style to GAP

Visio's default method of depicting connectors which cross but do not intersect is to illustrate one line arcing over the other. This is great for electrical drawings and other schematics, but isn't always accommodating of network topologies, especially when one line intersects a number of other closely-spaced lines.

For a cleaner look, we change the line jump style to "gap," which renders aesthetically pleasing white space to highlight line crossings. From the Developer tab on the ribbon, select Show ShapeSheet > Page. (If you don't have the Developer tab, go to File > Options > Customize Ribbon and enable it.) The page's ShapeSheet pops up in a window consuming the bottom half of the screen. Under the Page Layout heading, double-click the LineJumpStyle key and select "2 - visLOJumpStyleGap" from the available options. Press enter to save the selection.

I was recently tasked with configuring a number of 24-port Catalyst 2960S switches for deployment as standalone iSCSI switches for a storage area network (SAN). I haven't dealt much with SAN architecture so I wasn't sure what was needed. Obviously, just about any switch will support iSCSI right out of the box (it's just TCP/IP traffic, after all), but there are certain tweaks necessary to achieve the best possible performance.

Dell's PS Series Array Network Performance Guidelines outlines its recommendations for EqualLogic SAN arrays, including network configuration. This article parallels the Network Requirements and Recommendations section of that document.

Evaluating Switch Performance

According to the Catalyst 2960S data sheet, the 2960S-24xS-L series is capable of moving 41.7 Mpps worth of 64-byte packets, and its forwarding ceiling of 88 Gbps (which we could never reach with 24 GigE ports) leaves plenty of headroom. Since the traffic traversing this switch will be mostly iSCSI, which uses very long frames, the overall forwarding rate is much more important to us than the 64-byte packets-per-second limit (which is fairly high anyway).

Stacking

Similar to their big brother, the Catalyst 3750, multiple 2960S switches can be combined into a single managed unit through the use of proprietary stacking cables. Although the requirement here is for only a single switch, it's worth keeping in mind that the stack backplane introduces a potential 20 Gbps choke point for traffic switched among stack members. Obviously, this is more of a concern regarding 48-port switches than it is for 24-port switches.

I've touched on the fundamentals of DMVPN before, but today I'm going to expand upon my previous discussion and experiment with configuring multiple DMVPN clouds on a single pair of redundant headend routers. The scenario we'll use is that of a service provider offering DMVPN connectivity to two unrelated customers: Both customers need connectivity among their own sites and to the ISP, but must not be able to communicate with one another. Accordingly, each customer must use its own unique pre-shared key for authentication.

Our overall topology looks like this:

The 172.16.0.0/20 space represents public address space; in a real-world deployment, these would typically be effectively random public IP addresses.

The two ISP headend routers connect the four sites, two per customer, to the ISP network. Each headend router has two loopback interfaces (addressed out of 172.16.0.0/24) to which the DMVPN tunnels will be terminated. Per Cisco's DMVPN design guide, each customer will have two redundant DMVPN tunnels, one to each headend router. This adds up to a total of four DMVPN networks. Beware: this lab might get a little muddy, but I'll do my best to keep things clear.

Every now and then I find myself troubleshooting an issue at a remote customer site where hosts have limited connectivity to the rest of the world. For example, sometimes they can reach other private networks over a VPN, but apparently can't reach anything on the public Internet. In this scenario, the game is to deduce whether traffic is being dropped inbound or outbound. Unfortunately, there's no easy way to verify whether traffic is being dropped outbound beyond a device under your control.

So, last week I put together a simple tool to watch for ICMP echo requests (pings) sent to this site and publish a live stream of incoming traffic. This tool is Ping Watcher. (Get it? It watches pings.)

Ping Watcher employs Ajax and a simple back-end tied to a tshark process running on the public interface of this server. Send a ping, tshark catches it and writes it to round-robin memory structure (achieved using redis, and it will appear in Ping Watcher within a few seconds. Now you can confirm that traffic is at least getting from point A to the Internet, if not from the Internet to point B.

Hopefully this proves helpful to people. Let me know of any potential bugs or improvements you'd like to see.

And thanks to tbic and caaakeeey in #django on Freenode for some much-appreciate programming pointers!

Lately I've been looking for robust IP address management (IPAM) software to replace the unwieldy subnet spreadsheets I try to corral every day at work. You'd think this would be a fairly straight-forward task, but you'd be wrong. See, I work for a managed services provider (MSP), which acts in many respects as a sort of mini-ISP. We don't install or maintain physical circuits but we do act as a middleman for carriers who do, and we manage a large amount of address space both private and public, customer and internal. As an added bonus, we also have to carefully track how address space is imported and exported among hundreds of independent customer VRFs, which can potentially employ overlapping address space.

The problem I've encountered repeatedly whilst searching for an IPAM solution is that most of the products out there are intended to cater toward enterprise and datacenter customers. The key differentiating factor between these and an MSP or ISP is that enterprise and datacenter networks tend to focus on individual IP address allocations and DHCP leases, whereas service provider networks have a wider perspective, focused on IP prefixes and VRFs. As it turns out, there are surprisingly few IPAM solutions which favor the latter.

Here's what I've come across so far...

Today we'll look at a common scenario in which a single small site has two physical connections to the outside world: a private WAN link to a VoIP provider's MPLS cloud used to carry voice traffic, and a business-class broadband connection (e.g. cable, DSL, FiOS, etc.) used for direct Internet access. We want to enable dual failover for these links so that the broadband link can carry voice traffic in the event that the MPLS link fails, and so that the MPLS link can carry Internet-bound traffic in case the broadband link fails.

Topology

A local service provider has installed a 3 Mbps bonded T1 link to the site from its MPLS cloud to carry traffic to its VoIP services subnet (10.0.200.0/24). A dedicated circuit is necessary to support the QoS controls needed ensure acceptable voice call quality. The other link is a business-class broadband Internet circuit which is used for general Internet connectivity. BGP is running between the provider and customer site to advertise the relevant prefixes. A static default route has been configured on the customer router to direct all other traffic out the broadband link.

Note: The 172.16.0.0/12 space is used to represent public Internet addressing for the purposes of this lab.

Failover from MPLS to Internet

Our first task for this component of the configuration is to build a VPN between the customer site and the VoIP provider across the public Internet. For this lab, we'll configure a route-based IPsec VPN as discussed in Policy-Based vs Route-Based VPNs: Part 2. The tunnel will be addressed out of the provider's IP space with 10.4.87.0/30. The relevant configuration on the customer router is below. (Obviously, the provider's VPN router needs to be configured similarly.)

This article is a continuation of our discussion regarding policy-based versus route-based VPNs. Make sure to read through part one before continuing if you haven't already. In this second part, we'll look at configuring a route-based VPN on IOS and then examine some important differences between the two approaches.

Step 1: Create a pre-shared key

Route-based VPNs don't rely on an explicit policy (access list) to match traffic, so we can skip that step and start by creating a pre-shared key. On R1, we can re-use the keyring we defined in part one and simply add a new key for R5. On R5, create a new keyring and key for R1. (Use the same key on both routers.)

R1

crypto keyring VPN 
  pre-shared-key address 172.16.0.3 key MySecretKey
  pre-shared-key address 172.17.0.5 key AnotherSecretKey

R5

crypto keyring VPN
  pre-shared-key address 172.17.0.1 key AnotherSecretKey