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