When developing yet another Tcl script, I've stumbed across an interesting show command: the show ip access-list interface name introduced in IOS release 12.4(6)T displays the contents of the inbound and outbound IP access-list applied to the specified interface. The really nice part is that the ACL statistics (number of matches displayed next to the ACL lines) are kept and displayed per-interface.

I almost started writing an EEM applet that would detect and log the changes in router’s system time caused by NTP synchronizations, but then I’ve decided to check the IOS documentation first and found the ntp logging command.

The venerable rules used to establish OSPF router ID on Cisco IOS are all over the Internet:

• Take the highest IP address of all loopback interfaces configured on the router when the OSPF process is started.
• If there is no loopback interface, take the highest IP address of an operating interface.

In the old days, when Cisco believed that the router ID had to match an interface address, this also implied that the router ID would have changed if the interface IP address changed (and we told the students that you have to use loopback interfaces to make your network stable, as the OSPF process would restart if the interface giving the router ID went down).

The MPLS VPN implementation on Cisco IOS has always allowed you to create VRF static routes that pointed to interfaces belonging to other VRFs. The feature can be used to implement interesting overlapping VPN (or common services VPN) designs, some of which are explained in the MPLS and VPN Architectures books.

However, quite often the ability to create inter-VRF static routes is considered a major security problem, as an operator configuration error could establish undesired inter-VPN connectivity. In these cases, use the no ip route static inter-vrf configuration command to prevent such routes from being installed in the VRF routing table.

Shaun needed an extra TFTP server in CCNP labs and asked whether you could use a router to act as one. The read-only (download only) TFTP functionality has been available in Cisco IOS for a long time, but the common wisdom was that you could only use the TFTP server function to serve current IOS image.

Fortunately, as of IOS 11.0, the function is more generic; you can serve any file residing on the router (you still cannot upload files), but you have to declare each file to be served with the tftp-server path global configuration command. You could even specify an alias to have the file available under a different name and attach an access list to each configured file to restrict its availability.

If you use EEM applets with action syslog commands, the messages generated by those commands will be displayed in the same format as the debugging messages, regardless of their severity. This might be a problem if you decide to use different timestamps for debugging and regular syslog messages (or disable debugging timestamps completely).

In case you've missed yesterday's post … the weather was just way too good to stay in the office :) However, even if I would decide to work on my routers, I could take them with me (well, the laptop would be a bit heavy and the sun was too bright) thanks to Christophe Fillot (Dynamips) and Greg Anuzelli (Dynagen).

In case you haven't heard about Dynamips/Dynagen yet: Dynamips emulates a variety of IOS platforms (from 2600 to 7200) on Intel platform and Dynagen provides friendlier user interface (more than friendly enough for me, probably too cryptic for GUI addicts). I've seen Dynamips a year or two ago, checked what it can do and decided to stay with the real routers in a remote lab environment. In the meantime, the software has improved drastically, allowing you to test all sorts of IOS features and topologies, as long as you don't expect QoS to work or real-time features to act in real-time (simulation is, after all, a bit slower than the real life).

In the “good old days”, we've been teaching our students that although a router can act as a Frame Relay switch, it supports only the rudimentary functionality of switching the packets, but not the policing/marking features available in Frame Relay switches. That hasn't been true for a while - in IOS release 12.1T, Cisco has introduced the congestion management features. You can specify the congestion management per-interface (with the frame-relay congestion-management interface configuration command) and set the DE drop/ECN mark percentages for all PVCs on the interface, or you can set the parameters within a map-class.

Using DHCP to assign server IP addresses is usually not a wise decision. To start with, you have to define static DHCP mappings, which rely on client-id attribute in the DHCP request (usually the MAC address of the client). For me, the easiest way to find the correct client ID is as follows:

• Use DHCP to assign the IP address to the server
• Note the newly assigned IP address
• Use the show ip dhcp bindings | include ip-address command to display the client-id to IP address binding.
• Create a static DHCP mapping (for example, by configuring a host DHCP pool on the router) and release/renew IP address on the server

The "How could we figure out if any traffic uses the default route" challenge was obviously too easy; a number of readers quickly realized that the CEF accounting can do what we need (and I have to admit I've completely missed it).

However, when I started to explore the various CEF accounting features, it turned out the whole thing is not as simple as it looks. To start with, the ip cef accounting global configuration command configures three completely unrelated accounting features: per-prefix accounting (that we need), traffic matrix accounting (configured with the non-recursive keyword) and prefix-length accounting.