Reading the stories of Windows workstations becoming members of a spam botnet becomes way less enjoyable when you’re faced with the same problem (one of my kids managed to install a Trojan). It took me a day to clean the infected computer (it would have been easier to just format it, but the repeated installation of the Windows XP + Office software is so boring), but I’ve learned a few interesting networking lessons in the process that I’ll document in the next days.

I was very anxious to get my copy of Cisco Secure Firewall Services Module (FWSM) from Cisco Press, as I’m a purely router-focused person, and I wanted to understand the capabilities of the Firewall Services Module (PIX/ASA-like blade for the Catalyst 6500 switching system with virtual firewall capability). I have a good background in IOS-based firewalls and network address translation (NAT), so the book was a perfect fit for me. However, if you’re looking for “best practices for securing networks with FWSM,” you’ve been misled by the subtitle.

read more see 12 comments

read more see 2 comments

BFD is one of those simple ingenious ideas that make you wonder “Why did it take them so long to figure this out?” It’s a UDP-based protocol that replaces dozens of link-level failure-detection mechanisms and routing protocol tweaks with a simple, focused solution: detect hop-by-hop layer-3 failures.

In November 2008 IP corner article I described BFD principles, its configuration on Cisco IOS and give you practical examples how you can use BFD to improve next-hop failure detection. You’ll find the link to the article somewhere in this list.

I’ve received almost a dozen responses to the second OSPF challenge, most of them correct. The key to the solution is the way OSPF checks the neighbor’s IP address on point-to-point links (we already know that the subnet mask is ignored):

• If the interface is unnumbered, the router ignores the source IP address in the OSPF hello packets.
• If there’s an IP address configured on the interface, the router checks that the neighbor’s IP address (the source IP address in the OSPF hello packets) belongs to the same subnet. If the source IP address is not in the same subnet, the OSPF hello packet is ignored.

read more see 3 comments

Assuming you have the following configurations on R1 and R2:

hostname R1
!
interface Loopback 0
 ip address 10.0.0.1 255.255.255.255
!
interface Serial 0
 encapsulation ppp
 ip unnumbered Loopback0
 ip ospf 1 area 1
!
router ospf 1

hostname R2
!
interface Serial 0
 encapsulation ppp
 ip address 10.1.2.3 255.255.255.248
 ip ospf 1 area 1
!
router ospf 1

What IP address can you use on the loopback interface of R1 to establish adjacency between R1 and R2? Can you use more than one IP address?

I’ve received several e-mails responding to the mismatched OSPF subnet challenge. Some of the readers claimed that the configuration would work as-is; if you were one of them, I would advise you to do some lab tests the next time.

A few of the respondents also noted that it was more a review question than a challenge (since I’ve been writing about this topic a few days back), and everyone who decided the configuration has to be fixed has provided the correct solution: you have to configure the Fast Ethernet as a point-to-point OSPF interface and the routers stop complaining about the OSPF subnet mask mismatch.

One of my readers made an interesting observation in response to my “Knowledge or recipes” post: maybe network associates need recipes more than knowledge. My first reaction was to disagree; in my understanding, technicians work with recipes, engineers need to know what they’re doing and why. But then I tried to figure out what the term “networking associate” really means.