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.

I've got a simple question recently: “Can I run MPLS on a VLAN interface on 7600?” My initial response was “Sure, why not.”, as I knew we've deployed MPLS in 7600-based networks and there should be no significant difference between a routed port and a VLAN interface on a 7600 (this box treats everything as a VLAN internally).

It turned out the problem was "a small detail" that's not advertised in any 7600-related MPLS marketing material on Cisco web site: you need Advanced IP Services software to run MPLS. To make matters worse, the only mention of 7600-series devices in the Cisco IOS Packaging Product Bulletin I've finally found within the 7600 routers product literature is in the first marketing slide.

This article is part of You've asked for it series.

My IP QoS: Two generations of class-of-service tools article published by SearchTelecom gives you a very high-level overview of IntServ and DiffServ approaches to IP QoS as well as brief description of various DiffServ tools.

More to explore:

• More QoS articles
• QoS Fundamentals webinar

A short question I've got from Shahid Rox:

Today I read your article about scaling EIGRP using stub routers. I was wondering whether you can use the leak map only for routes learned from other EIGRP neighbors? Is it also usable to filter connected routes?

Leak-map controls what its name implies: the leakage of routes received from EIGRP neighbors to other EIGRP neighbors. To filter connected prefixes redistributed into EIGRP, use the route-map on redistribute connected command. The only way I've figured out to filter announcements of directly connected networks that are part of the EIGRP process is the distribute-list out command.

When the local Telco installed my blindingly fast 20 Mbps Internet-over-fiber-cable service, I was expecting to use DHCP on the router’s outside interface to connect to the Internet. After all, they’re running switched Ethernet VLANs over the fiber cable, and using DHCP seemed a logical choice. Imagine my surprise when I had to configure PPP-over-Ethernet (PPPoE) – it was as if I would be using a DSL connection, not a fiber-optic cable.

Yesterday, I introduced a scenario where RIP would (in my opinion) work much better than OSPF. If you were not persuaded by the “management-level” arguments, let’s focus on the technical details (but make sure you read the scenario first).

All you ever want to advertise to the remote sites in this design is the default route (or a network-wide summary). Alternatively, you might want to advertise only a route to a central LAN or server. Both requirements are easily met with RIP per-interface output filters. Doing something similar with OSPF is close to impossible. Either you place every remote site into a separate OSPF area (don’t even think about doing it; there could be hundreds of sites), or the routes within an area will leak between the remote sites.

RIP is also more stable than OSPF in this setup. Whenever a remote site disappears, the change in the OSPF area is unnecessarily propagated to all other remote sites in the same area. RIP doesn’t propagate the topology change; the central site’s output route filter stops all unnecessary updates.

As you know, OSPF requires hello packets and adjacencies to work correctly. Therefore, the central hub router must track the adjacency states of hundreds of neighbors. When using RIP, the central router couldn’t care less … it sends out its routes every so often, collects whatever comes back, and reports when a new remote route is received, or an old one disappears.

After working with MPLS Traffic Engineering lab for a few days and interpreting IP addresses from various traceroute outputs, I finally had enough and wrote a simple Perl script (below) that parses router configurations and produces ip host configuration commands for every interface IP address it encounters. When you paste the ip host commands into the configuration of the edge router from which you do the tests, the meaningless numbers finally make sense.