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.

For more details on how BFD interacts with the routing protocols watch the How Networks Really Work webinar.

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.

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?

You can find the solution here.

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.

Someone recently asked me how to get the physical location of an IP address. One of the better (free) services available on the Internet is the IP2Location (demo) service.

This feature might come handy if you're trying to figure out who's attacking your application servers (when the TCP session has already been established). Denial-of-service attacks commonly use fake source IP addresses.

A few days after my “Knowledge or Recipes” post, Greg Ferro started his “Experience or Certifications” series with a radical “I would always choose certification over experience” approach that quickly moderated into “Knowledge is more fundamental than experience … but you need both”. It’s nice to see someone else thinking along the same lines as yourself.

You could get something like this only in a CCIE lab (I would hope): R1 and R2 should establish OSPF adjacency, but you cannot change or remove any of the existing configuration commands (you can add new commands).

A while ago cciepursuit described his problems with PPP-over-Frame Relay. Most probably his problems were caused by a static IP address assigned to the virtual template interface (this address gets cloned to all virtual access interfaces and IOS allows you to have the same IP address on multiple WAN point-to-point links). I recreated a very similar (obviously seriously broken) scenario in my lab using point-to-point subinterfaces over Frame Relay to simplify the setup.

The common wisdom says that the subnet mask mismatch will stop the OSPF adjacency from forming. In reality, the subnet mask is checked only on the multi-access interfaces and is ignored on point-to-point links. The source of this seemingly weird behavior is the Section 10.5 of RFC 2328, which says:

The generic input processing of OSPF packets will have checked the validity of the IP header and the OSPF packet header. Next, the values of the Network Mask, HelloInterval, and RouterDeadInterval fields in the received Hello packet must be checked against the values configured for the receiving interface. Any mismatch causes processing to stop and the packet to be dropped. In other words, the above fields are really describing the attached network's configuration. However, there is one exception to the above rule: on point-to-point networks and on virtual links, the Network Mask in the received Hello Packet should be ignored.

Troubleshooting OSPF adjacencies can be a nightmare: if you’ve misconfigured the OSPF interface parameters (the timers or the subnet mask), the adjacency will not form, but the router will not tell you why. The only mechanism you can use to detect the mismatch is the debug ip ospf hello command … just don’t try to use it on a console session of a router running OSPF across hundreds of interfaces.

The OSPF hello event debugging does not display OSPF packets received from a different subnet. If you configure mismatched IP subnets (not the subnet mask) on adjacent routers, you will not see any received hello packets.

Several comments I’ve received in response to my “Knowledge or recipes” post were slightly resigned, leading me to the unfortunate conclusion that you all gave up and decided to live with the current state of the IT training business. But you can do something about it – go out and vote!

I’m constantly receiving interesting OSPF-related queries – the many hidden details of the OSPF specs result in slightly unexpected behavior and constant amazement of engineers studying OSPF. During this week, I’ll focus on a few intriguing OSPF details.

Let’s start with an easy one: you can use the show ip ospf interface brief command to display the OSPF interface status (including the interface area, OSPF cost, link type, and router status on broadcast links). Unfortunately, this command does not allow you to specify the OSPF process ID and displays interfaces belonging to all OSPF processes (if you run multiple OSPF processes on the router). ::: Here is a sample printout taken from a router running OSPF processes #2 and #13:

C1#show ip ospf interface brief
Interface    PID   Area    IP Address/Mask    Cost  State Nbrs F/C
Lo102        2     22      10.2.2.2/32        1     LOOP  0/0
Fa0/0        13    0       10.0.1.1/24        10    BDR   1/1
Lo0          13    0       10.0.0.11/32       1     LOOP  0/0
Se1/0.101    13    1       0.0.0.0/0          64    P2P   1/1
Se1/0.100    13    1       0.0.0.0/0          64    P2P   1/1

You can use an output filter to display the interfaces of a single OSPF process. The filter is quite convoluted:

C1#show ip ospf interface brief | include ^[^ ]+ +13
Fa0/0        13    0       10.0.1.1/24        10    BDR   1/1
Lo0          13    0       10.0.0.11/32       1     LOOP  0/0
Se1/0.101    13    1       0.0.0.0/0          64    P2P   1/1
Se1/0.100    13    1       0.0.0.0/0          64    P2P   1/1 

It works like this:

• The initial caret (\^) matches the beginning of the line, ensuring that our filter matches precisely what we expect it to match. Without the initial caret, the filter could generate a match anywhere in the line, potentially resulting in false positives.
• The [^ ]+ pattern matches any non-empty (the + sign) string of non-space characters (the [^ ] expression matches anything but the whitespace). This part of the pattern matches the interface name.
• The  + pattern matches the string of spaces between the interface name and the process ID.
• The final part of the pattern (13) matches the OSPF process ID.