Update: The “show ip interface” command I've always wanted to have

After I've published the Tcl script that displays the interface IP parameters in a formatted table, cos quickly pointed out a bug: I've expected the IP addresses in the address mask format. In the meantime, I've figured out the root cause of the problem (our remote labs are set to display IP masks in decimal format for compatibility reasons) and fixed the Tcl script. It temporarily sets the terminal ip netmask-format to bit-count before executing the show command. The new script recognizes three parameters:

• active: display only interfaces that are up/up;


• configured: display only interfaces with configured IP addresses (unnumbered interfaces using IP address of an interface without one count as configured since IOS reports their IP address as 0.0.0.0).


• address: displays IP address of the unnumbered interface, not the interface that it's borrowing the address from.

You can view the Tcl source or download it from my web site.

Changing the format of IP routes

The comment to one of my previous posts reminded me of a cool feature that's been available in Cisco IOS for a number of years - you can change how the IP addresses and routes are displayed in various show printouts (but not in the router configuration) with the terminal ip netmask-format bit-count|decimal exec-level command. You can even make the change permanent by configuring ip netmask-format format on console and VTY lines.

And the funniest part of the whole story is that I was utterly impressed with the feature when it was introduced ... and now almost started to reinvent the wheel and implement the same functionality in Tcl

Update: Preparing for the MPLS CCIP exam

Following my post about the relationship between the MPLS and VPN architectures books and CCIP MPLS exam, Peter Dob had an excellent idea: combine the MPLS and VPN architectures (Volume I, CCIP edition would be even better) with the MPLS fundamentals from Luc de Ghein. By reading Luc's book, you'll also get exposure to other MPLS-related topics (for example, AToM) on top of MPLS TE overview that you need for the exam.

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

Inspection of router-generated traffic does not recognize DHCP client traffic

After I've published a post on how you can use the new router-traffic keyword to minimize the Internet-facing access list you use with CBAC, Euphrates Greene pointed out to me that this feature does not work for client DHCP traffic (if the router is acting as a DHCP client, for example, when connected to a MAN Ethernet environment).

Once you start thinking about what's really going on, it all becomes obvious: as the router has no IP address when it sends the DHCP request, and it sends the DHCP request to a broadcast address (as it doesn't know the IP address of the upstream DHCP server), there is no session that could be entered into the CBAC session table. So you still have to allow all DHCP traffic to your router with an access-list similar to this one:

ip access-list extended Internet
 permit udp any eq bootps any eq bootpc
 deny ip any any

Note: Replace the highlighted any keyword with the actual DHCP server's IP adress if you have it available and you want to have an even more secure IP access-list.

Redundant small-site multihoming

The February IP Corner article Small Site Multi-Homing described how to implement Internet multihoming without having your own IP address space or BGP autonomous system number. The article has generated lots of responses, most of them being questions about redundant implementation of the same principles. The fully redundant design is described in the July article, Redundant Small Site Multi-Homing.

DHCP and BOOTP coexistence

If you have an existing BOOTP environment (for example, a set of old Unix workstations and X-terminals) and want to deploy DHCP on the same LAN segment, you could run into interesting compatibility issues, as the DHCP servers by default responds to BOOTP requests.

However, IOS has an interesting feature when you use a router as a DHCP server: you can tell it to ignore the BOOTP requests with the ip dhcp bootp ignore global configuration command (introduced in 12.2T and 12.3). Even more, the router can respond to DHCP requests and forward BOOTP requests to a non-local BOOTP server configured with the ip helper-address interface configuration command.

IOS doesn't have Unix-style pipes

Recently one of my readers asked an interesting question:

“It looks like the second pipe character (¦) in an output filter is interpreted as an OR, not as yet another filter. How can I thus implement a filter that will match string_a AND string_b?

As explained in my IP Corner article Enhance the IOS user interface, the output filters are extensions of the show command. The first ¦ character starts the filter specification and anything after the first keyword is part of a regular expression (where ¦ means or).

To match a combination of two strings, you could either write a small Tcl script or use a more convoluted regular expression where you combine both strings into a single expression (inserting .* between them to match any intermediate set of characters). For example, to find all static host routes in your router configuration, you could use the following filter:

show running | include ip route.*255\.255\.255\.255

Note: The \. matches the dot character, whereas the . matches anything.

Totally Stealthy Router

In response to the post detailing router response to port scans, one of my readers asked an interesting question:

“I was wondering if there was a way to prevent the router from sending those TCP RST packets administratively prohibited ICMP messages back to scanners for TCP and UDP respectively. I basically want my router to drop all packets period without replying back in any way, shape, form, or fashion.”

Here's how you do it:

• No TCP RST packets should be sent as responses to port scans. Inbound access list dropping all IP packets achieves that.
• Outbound traffic, both from the protected LAN as well as from the router itself (ping, telnet, DNS, NTP ...) should be allowed. Configure ip inspect with router-traffic option.
• Disable generation of ICMP unreachables with the no ip unreachables interface configuration command.

The relevant parts of router configuration are included below:

ip inspect name Internet tcp router-traffic
ip inspect name Internet udp router-traffic
ip inspect name Internet icmp router-traffic
!
interface FastEthernet0/0
 ip address a.b.c.d x.y.z.w
 ip access-group Internet in
 no ip unreachables
 ip inspect Internet out
!
ip access-list extended Internet
 deny ip any any

Notes:

• The sample router configuration is taken from a SOHO router doing PAT on the public interface. You might have to adjust the Internet access-list to your needs.
• This article is part of You've asked for it series.

Be smart when using the OSPF network statement

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 obviously 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 IOS is also pretty helpful recently: 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 network implementations, I use the network statements in three different ways:

• If I have to assign a specific interface into an area, I would always use network x.y.z.w 0.0.0.0 area n;
• If the area address ranges are nicely assigned (which also helps immensely when you have to start summarizing), you can use a single network statement to cover the whole area. If, for example, area 3 has address range 10.1.16.0/20, use network 10.1.16.0 0.0.15.255 area 3;
• If the router has all interfaces in a single area, I would almost always use network 0.0.0.0 255.255.255.255 area area-id (unless there is an extremely good reason that some interfaces should not be seen by the OSPF process).

Update: Inspect router-generated traffic

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.

Furthermore, if you use any protocols that have separate control and data sessions (for example, FTP, H.323 or SIP), you have to list them before tcp or udp keywords, otherwise their control streams will not be inspected and there will be no provision for data sessions.

ip inspect name Internet ftp
ip inspect name Internet h.323 router-traffic
ip inspect name Internet sip router-traffic
ip inspect name Internet tcp router-traffic
ip inspect name Internet udp router-traffic
ip inspect name Internet icmp router-traffic
!
interface FastEthernet0/0
 ip access-group Internet in
 ip inspect Internet out
!
ip access-list extended Internet
 deny ip any any

Redundant DHCP server

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:

ip dhcp pool LAN
 network 192.168.1.0 192.168.0.0 255.255.255.0
!
! Exclude router addresses
ip dhcp excluded-addresses 192.168.0.1 192.168.0.10
!
! Exclude half of the pool
ip dhcp excluded-addresses 192.168.0.128 192.168.0.255

Alternatively, you can rely on the ip dhcp ping packets command; the router will ping an IP address to check whether it's live before assigning it (by default, the router sends two pings with 500 millisecond timeout).

Note: You can also inspect the conflicting IP addresses the router found with the show ip dhcp conflict command.

Network statements are no longer needed in OSPF configuration

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.

In IOS release 12.3(11)T (integrated in 12.4), Cisco finally implemented OSPF the way it should have been implemented 20 years ago - you configure the OSPF area on individual interfaces with the ip ospf process area area-id interface configuration command.

The network statements still work as expected and the per-interface command overrides whatever the network statement would do, so you have an extremely nice combination that allows you to assign all interfaces into a particular area (for example, network 0.0.0.0 255.255.255.255 area 2) and change the area for only a few interfaces (for example, uplinks into the backbone area).