For whatever reason, a lot of people have the impression that the wildcard bits in the OSPF network statement have to be the inverse of the interface subnet mask. For example, if you have configured ip address 192.168.1.2 255.255.255.240 on an interface, they would enter network 192.168.1.2 0.0.0.15 in the OSPF configuration (and use one network statement per interface).

In reality, the network statements work like simple IP access-list: whenever an interface IP address matches the network statement, the interface is put into the selected area. The Cisco IOS CLI got better over the years: the network statements are automatically sorted from most-specific to least-specific and (like with the access lists) the first match stops the search.

In my previous post, I've described how you can get a very clean configuration with no holes in your Internet-facing access-list if you have IOS release that supports inspection of router-generated traffic. As it turns out, my solution was not complete - you could not ping from the router. On top of inspecting UDP and TCP traffic (as is usually done), you also have to inspect ICMP traffic that the router uses for pings.

If you want to build a truly redundant LAN infrastructure, you should also have redundant DHCP servers. If you decide to do the DHCP address allocation locally (on the router), you should take care that the two routers acting as DHCP servers don't assign overlapping addresses.

If the address space assigned to a LAN is at least twice as large as the number of LAN-attached devices, you can use the ip dhcp excluded-addresses command to exclude half of the address pool on each router, for example:

If you’ve ever had to configure OSPF on a Cisco router, you’re well familiar with the venerable network statement, which effectively assigns interfaces into OSPF areas based on their IP addresses. Although our life became simpler when the network statements stopped being order-dependent (the order dependency allowed for a few nasty surprises in the troubleshooting part of the CCIE lab when the CCIE title still implied you had to be able to fix other people’s mistakes :), it was still an awkward way of configuring what belongs where.

Every now and then I'm getting questions from my readers regarding the suitability of my MPLS books for the CCIP exam, for example:

I'm pursuing my CCIP and have a hard time finding the right MPLS study guide. I know you have the CCIP edition that was written in 2002, but I think the exam topics have changed. Can you recommend what book or books are best for the CCIP MPLS exam?

Are MPLS VPN Architectures Volume 1 & 2 two completely separate books or is Volume 2 a newer release. I was thinking of going for the CCIP and wanted to know if I should get both books or just the more recent one.

Here’s an interesting OSPF-related question I got::

“Which one is better: default-information originate or default-information originate always?”

As always, the answer is it depends. If your OSPF edge routers have external default routes (for example, static default routes toward the Internet, see the next diagram), you'd want them to announce the default route only when they have a default themselves (otherwise, they would attract the traffic and then blackhole it). In this case, you’d use default-information originate.

Another Cisco IOS OSPF implementation trivia: if you’re redistributing a default route into OSPF (for example, you have a static default route configured with ip route 0.0.0.0 0.0.0.0 … and you use redistribute static subnets within the OSPF process), the default route will not be entered into the OSPF database unless you configure default-information originate within the router ospf configuration.

Similarly, if you configure default-information originate always, the router will inject the type 5 LSA for the default route into the OSPF topology database even if the router itself does not have a default route (or gateway of last resort).

Similar to the show processes cpu sorted command, the show processes memory sorted printout displays the top memory consumers (see example below).

Recently, I was investigating MTU-related problems and got mightily upset when I had to search for the interface IP MTU size in the long printout produced by the show ip interface command. Obviously, I could display the IP MTU for a single interface with the show ip interface name | include MTU filter, but I wanted a nice tabular printout. Obviously, it was time for another Tcl script.

To use it, download it and store it in the flash memory of your router. Configure alias exec ipconfig tclsh flash:ipInterfaces.tcl and you can use ipconfig or ipconfig active to display interface IP addresses.

One of the hardest troubleshooting problems within an MPLS VPN network has always been finding a broken LSP. While you could (in theory) use the IP ping or traceroute (assuming all hops support ICMP extensions for MPLS), the results are not always reliable… and interpreting them is not so easy. For example, after I've disabled LDP on an interface with the no mpls ip configuration command, the routers in the LSP path still reported outgoing MPLS labels in ICMP replies for a few seconds (until the LDP holddown timer expired on both ends of the link).

As a side note, would you deduce from the printout that the break in the LSP path happened on the router with the IP address 192.168.201.1?