Here’s one in a series of many stories of failure, frustration, and figuring things out.

I’ve been studying for Cisco’s CCNA certification recently and decided to purchase some older gear in order to set up a test lab, familiarize myself with IOS, and get used to the the physical wiring/configuration of these devices. Thus far, I’ve had some fun putting everything together, learned a lot in a short span of time, and I can still afford rent. My first router came in the mail the other day, so I figured I’d set up a basic layout in order to test its functionality.

The goal was simple enough: 2 hosts (a Windows 7 laptop and a Raspberry Pi running Raspbian), 2 2950 switches, and a 2651XM router in the middle. Set them up, ping back and forth.

Simple enough, right? If you answered “yes”, congratulations on being as arrogant as I was. This simple setup threw me for a loop, taking several hours to properly configure and causing me to question the hardware involved, basic routing and networking theory, and my sanity in general.

With a plan in place and success assumed, off I went. Console to each switch, config, console to the router, config. I assigned IPs to the router’s Ethernet ports, defined my routes. Interfaces are up, green LEDs everywhere, I’m good to go.

And then I ping, and then it fails. So I ping from the other PC, and it still fails. Hmm. Basic network troubleshooting skills kick in, and I start pinging out from the host to each successive link. At both sides, all goes well until pinging the router’s external interface, the point where the two networks connect and my packets fall off a cliff. This doesn’t make sense! Those interfaces are physically connected. How could the router be so stupid as to not know how to direct the requests? I check the routing table, all looks well. I run out of ideas and begin to gradually cycle between the stages of the Kübler-Ross model of grief.

To make this whole process a little easier, each PC also had a wireless interface connected to my home network, enabling me to SSH/TeamViewer in to either. This was my first mistake. As the host had no idea where the 192.168.3.x network was, it was sending the ping requests out of the wrong interface.

Previously, I had set up an IP for the management VLAN on each switch, which ended up being helpful in solving the last few pieces of the puzzle. I hopped back onto the switches and found that once I had the default gateways properly configured to the router’s connected interface, I could ping between the switches, crossing the router. OK, so the router’s good, switches can communicate, but pings from the hosts stop at the router’s internal interface, and pings from the switch to the host stop at the switch on the other side. Feeling defeated and figuring I’d probably be a networking philistine for the rest of my life, I decide to sleep on it. I wake up the next morning, the eureka moment hits, and I scramble back to the PCs.

I configure static routes from the PCs to the router’s internal interfaces for the networks needed.

Ping from the Windows PC: Great success!
Ping from the Linux PC: Great fail!

Wait, what?

I double-check the route, it looks OK. I’m perplexed. I start to wonder if the guys from “Windows Tech Support” that keep calling me can actually help out on this one.

Here’s my second mistake: I’d become so conditioned to pinging within the same subnet on Windows machines that I assumed it also worked the same way for pinging from an external network. This is not so. Windows Firewall blocks ICMP echo requests from external networks, which is required to ping from external hosts. This explains why I was able to ping from the adjacent switch and router, but not across the router’s interfaces.

Windows Firewall > Advanced Settings > New Inbound Rule > Custom Rule > Protocol Type > ICMPv4 > Any IP > NextNextNextNextNextNext problem solved. I am now a hero in my own mind.

What are the takeaways from this ordeal? A. Consider how the hosts will rout if multiple interfaces are configured and share a default gateway without any static routes. B. Consider how different operating systems react to traffic and requests. C. Question the obvious. D. Don’t get cocky.