Building Network Automation Solutions
6 week online course starting in September 2017

Remove the configuration prompt

I should probably write this one on April 1st, but maybe October 31st is not such a bad choice after all … if you configure no service prompt config, the configuration prompt is gone; when you enter the configuration mode with the configure terminal command, you get an empty line (like you did with Cisco software release 9.1 some 15 years ago). Similarly, you can disable command-line editing with the no editing line configuration command or terminal no editing exec-level command. If only there would be a way to disable the context-sensitive help :)

More details on OSPF route filters

I did a few follow-up tests with the distribute-list in OSPF configuration command and stumbled across a few interesting facts (IOS release 12.4(15)T1 on a 3725 platform):

  • Although the router allows you to configure distribute-list acl in interface, it does not work. Routes received through that interface (or having the interface as the next-hop) are not filtered.
  • When you apply the distribute-list in command, the routing table is not changed. Clearing the IP routing table does not help, you have to clear ALL OSPF processes (including bringing down all OSPF adjacencies) with the clear ip ospf process command for the route filter to take effect.
  • The same limitations don't apply in the other direction: when you remove the distribute-list in, SPF is triggered and the routes appear in the IP routing table automatically.
  • The somewhat undocumented gateway option of the distribute-list in command works, but not quite as I would expect: the IP next hop, not the router-ID of the router advertising the IP prefix is matched by the prefix-list.

And, last but not least, I've lab-verified my previous claim: applying the distribute-list in on a transit router can result in a black hole, as the LSAs themselves are not filtered.

Send an e-mail when an interface goes down

John S. Pumphrey recently asked an interesting question: “Can the router send an e-mail when an interface goes down?” The enterprisey solution is obvious: deploy a high-end EMS to collect SNMP traps and use its API to write a custom module that would use a MQ interface to alert the operator. Fortunately, Event Manager applets in Cisco IOS provide action mail command (available in 12.3(14)T and 12.4) that can send an e-mail to a SMTP server straight from the router.

There are two ways you can detect that an interface went down with EEM: either you track the interface status with a track object and start an EEM applet when the track object changes state or you catch the syslog messages reporting that the interface line protocol changed state to down. The second approach is obviously more generic, as a single applet can act on multiple interfaces.

event manager applet MailOnIfDown
 event syslog occurs 1 →
    pattern "LINEPROTO-5-UPDOWN.*to down" →
    period 1

Notes:

  • If you want to limit the applet to serial interfaces only, you could change the pattern to LINEPROTO-5-UPDOWN.*Serial.*to down.
  • The → continuation character is used to indicate that a single configuration line has been split to increase readability.

The action mail command specifies the mail server's address (use a hostname and DNS lookup or ip host configuration command to make the EEM applet more generic), from and to address, message subject and body. In each of these fields, you can use EEM environment variables that you can define with the event manager environment configuration command. Each EEM event also defines a few environment variables that you can use (see the table of EEM system-defined variables on CCO). For example, you can define the e-mail recipient in the router's configuration and use the _syslog_msg variable to include the syslog message in the e-mail body:

event manager environment _ifDown_rcpt admin@lab.com
!
event manager applet MailOnIfDown
 event syslog occurs 1 →
    pattern "LINEPROTO-5-UPDOWN.*to down" →
    period 1
 action 1.0 mail server "mail-gw" →
    to "$_ifDown_rcpt" from "R1@lab.com" →
    subject "Interface down on R1" →
    body "$_syslog_msg"

You can make the applet even more generic with the help of action info type routername command, which stores the current router's name into the $_info_routername environment variable:

event manager environment _ifDown_rcpt admin@lab.com
!
event manager applet MailOnIfDown
 event syslog occurs 1 →
    pattern "LINEPROTO-5-UPDOWN.*to down" →
    period 1
 action 1.0 info type routername
 action 2.0 mail server "mail-gw" →
    to "$_ifDown_rcpt" from "$_info_routername@lab.com" →
    subject "Interface down on $_info_routername" →
    body "$_syslog_msg"

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

Display a summary of OSPF interfaces

When I was lab-testing the ideas for my article on EIGRP-to-OSPF migration, I had to check the OSPF interface cost ... and complained immensely at the amount of information produced by the show ip ospf interface command. Luckily I've double-checked before starting to write a Tcl script and realized that a brief keyword was added in IOS release 12.3, producing exactly the printout I was looking for.On my test router, the show ip ospf interfaces brief command produced this nicely-tabulated printout:

a1#show ip ospf interface brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Lo0 1 0 172.16.0.11/32 1 LOOP 0/0
Se0/0/0.100 1 0 172.16.1.1/30 50 P2P 1/1
Fa0/0 1 0 10.0.0.5/24 1 BDR 1/1
Fa0/1 1 11 10.1.2.1/24 1 DR 0/0

The netmask-format of your line has to be set to bit-count for this command to work properly, otherwise the columns will be shifted to the right.

Debugging cached CEF adjacencies

A while ago I wrote about cached CEF adjacencies and the impact they have on ARP caching. If you ever need to, you can debug them with the debug ip cef table command. As this command might produce a lot of output in a production network, always use it in combination with an access-list that limits the debugging to the selected address range.

Alternatively, you can use the debug arp adjacency command, but you cannot limit its output with an access-list

For example, to test cached CEF adjacencies in subnet 10.0.0.0/24, I've used the following commands:
rtr#show ip access-list 99
Standard IP access list 99
10 permit 10.0.0.0, wildcard bits 0.0.0.255 (26 matches)
rtr#debug ip cef table 99
IP CEF table debugging is on for access list 99
rtr#debug arp
ARP packet debugging is on
rtr#ping 10.0.0.10

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.10, timeout is 2 seconds:

08:57:27: IP ARP: creating incomplete entry for IP address: 10.0.0.10 interface FastE
thernet0/0
08:57:27: IP ARP: sent req src 10.0.0.6 0016.c876.8b38,
dst 10.0.0.10 0000.0000.0000 FastEthernet0/0
08:57:27: IP ARP: rcvd rep src 10.0.0.10 000c.29a7.8ade, dst 10.0.0.6 FastEthernet0/0
08:57:27: CEF-IP: Checking dependencies of 10.0.0.0 255.255.255.0
08:57:27: CEF-Table: Adjacency-prefix 10.0.0.10 255.255.255.255 add request -- succee
ded.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/4 ms
rtr#

OSPF neighbors stuck in EXSTART

This problem is quite rare, but tantalizing enough to warrant mentioning: OSPF neighbors are forever stuck in EXSTART state (occasionally going to DOWN and back to EXSTART).

I've actually stumbled across it accidentally in my lab and have luckily seen it before, so I knew immediately what it was.

The moment you start suspecting that something might be wrong with the OSPF adjacencies and use debug ip ospf adj command, the problem becomes obvious: the Database Description packet contains an Interface MTU field and if the value received from the neighbor is higher than the IP MTU configured on the inbound interface, the DBD packet is rejected (section 10.6 of the RFC 2328). The router with the lower MTU complains that “Nbr x.x.x.x has larger interface MTU” and the other router moans about protocol violations (First DBD and we are not SLAVE).

As always, there are two ways to solve this problem:

  • The correct one: fix the MTU issues;
  • The other one: disable MTU checks with the ip ospf mtu-ignore interface configuration command (which might be OK as long as the hardware is able to receive oversized packets and the router is not using fixed-size input buffers).

GRE tunnel keepalives

The IP-over-IP (usually GRE) tunnels (commonly in combination with IPSec to provide security) are frequently used when you want to transport private IP traffic over public IP network that does not support layer 3 VPNs. If you use the GRE tunnels in combination with default routing (or route summarization), you can get serious routing issues when the tunnel destination disappears, but a default (or summary) route in the IP routing table still covers it. You could work around this issue by deploying a routing protocol over the GRE tunnel (which could lead to hard to diagnose routing loops if you're not careful) or by using GRE keepalives introduced in IOS release 12.2(8)T.

The implementation of the GRE keepalives is amazing: the router sending the keepalive packet constructs a GRE packet that would be sent from the remote end back to itself (effectively building a GRE reply), sets the GRE protocol type to zero (to indicate the keepalive packet) and sends the whole packet through the tunnel (effectively encapsulating GRE reply into another GRE envelope). The receiving router strips the GRE envelope and routes the inside packet … which is the properly formatted GRE keepalive reply.

This trick allows you to implement different GRE keepalive timers on each end of the link. For example, the remote site might use fast keepalive timers to detect loss of primary link and switch over to a backup link, while the central site would use less frequent keepalive tests to detect failed remote site (if there is a single path to the remote site, you don't care too much when you detect it's down).

Every ingenious solution has its drawbacks and this one is no exception: if the receiving router protects its IP addresses (to stop spoofing attacks), it will drop the incoming GRE keepalive packet. Furthermore, a document available on Cisco's web describes the issues of using GRE keepalives in IPSec environment.

Tabular display of interface MTUs

When I started exploring the details of MTU handling in Cisco IOS, I quickly got tired of analyzing various long printouts to extract the MTU sizes, so I wrote a Tcl script that display hardware, IP and MPLS MTUs in a tabular format. To install it on your router:

  1. Download it from my web site and copy it to your router's flash or NVRAM.
  2. Define an alias, for example alias exec mtu tclsh flash:displayMTU.tcl.

The script recognizes two parameters: the ip parameter displays only the interfaces that have IP configured and the mpls parameter displays only the MPLS-enabled interfaces.

Here is a sample printout from one of my lab routers:
R2#mtu
Interface Hardware IP MPLS
=========================================================
FastEthernet0/0 1500 1600
FastEthernet0/1 1500
Serial1/0 1500 1500
Serial1/1 1380 1380 1430
Serial1/2 1500 1500
Serial1/3 1500
Loopback0 1514 1514
Tunnel0 1514 1476 1476

R2#mtu mpls
Interface Hardware IP MPLS
=========================================================
FastEthernet0/0 1500 1600
Serial1/1 1380 1380 1430
Tunnel0 1514 1476 1476
You can find more Tclsh-related information in the Tclsh on Cisco IOS tutorial. Sample Tclsh scripts are available in the Tclsh script library. If you need expert help in planning, developing or deploying Tclsh scripts in your network, contact the author.

ICND1 blended learning

If you're a regular reader of my blog, you probably won't need this one, but it might be useful to your colleagues who are reaching for the first rung on the Cisco certification ladder.

If your first thought was CCNA, you're wrong; Cisco came up with a sub-CCNA certification called Cisco Certified Entry Networking Technician.

We've just rolled out a blended e-learning version of the requisite ICND1 (yes, that is ICND part one) course containing student guides in e-learning format and all the associated remote lab exercises (performed on actual devices, no simulations).

Get creative: OSPF route filters

A few of the readers pointed out that I've forgotten about OSPF route filters in the post I wrote about running OSPF across the firewall. Actually I didn't, as it's only available in IOS, not in ASA/PIX. However, this is not the familiar route update filtering available in EIGRP, BGP or RIP. The route updates (LSAs) are not filtered (as they should not be in a link-state protocol); the filters control the transfer of the IP prefixes from the SPF tree to the IP routing table.

To keep the record straight, I have to point out that this is not a new feature. You could have achieved similar results (almost) forever with the distance 255 command (remember: 255 = totally unbeliavable = not installed). Later on, you could use the distribute-list in router configuraton command and in 12.2T this command has been extended to accept a route-map.

However, as this functionality is totally different from the distance vector route filters and doesn't play well with OSPF concepts, you have to use it very carefully. Every OSPF router still propagates all the LSAs, but if it fails to install the resulting IP prefixes in the IP routing table, it's a potential blackhole (see the following figure).


With all this being said, I cannot see the “OSPF inbound filtering” as it's slightly inappropriately named being widely used. Do you have any great scenarios where this feature would be really helpful?

The tale of the three MTUs

An IOS device configured for IP+MPLS routing uses three different Maximum Transmission Unit (MTU) values:

  • The hardware MTU configured with the mtu interface configuration command
  • The IP MTU configured with the ip mtu interface configuration command
  • The MPLS MTU configured with the mpls mtu interface configuration command

The hardware MTU specifies the maximum packet length the interface can support … or at least that's the theory behind it. In reality, longer packets can be sent (assuming the hardware interface chipset doesn't complain); therefore you can configure MPLS MTU to be larger than the interface MTU and still have a working network. Oversized packets might not be received correctly if the interface uses fixed-length buffers; platforms with scatter/gather architecture (also called particle buffers) usually survive incoming oversized packets.

IP MTU is used to determine whether a non-labeled IP packet forwarded through an interface has to be fragmented (the IP MTU has no impact on labeled IP packets). It has to be lower or equal to hardware MTU (and this limitation is enforced). If it equals the HW MTU, its value does not appear in the running configuration and it tracks the changes in HW MTU. For example, if you configure ip mtu 1300 on a Serial interface, it will appear in the running configuration as long as the hardware MTU is not equal to 1300 (and will not change as the HW MTU changes). However, as soon as the mtu 1300 is configured, the ip mtu 1300 command disappears from the configuration and the IP MTU yet again tracks the HW MTU.

The MPLS MTU determines the maximum size of a labeled IP packet (MPLS shim header + IP payload size). If the overall length of the labeled packet (including the shim header) is greater than the MPLS MTU, the packet is fragmented. The MPLS MTU can be greater than the HW MTU assuming the hardware architecture and interface chipset support that (and the router will warn you that you might be getting into trouble). Similar to the ip mtu command, the mpls mtu command will only appear in the running configuration if the MPLS MTU is different from the HW MTU. However, contrary to the behavior of the IP MTU, any change in HW MTU with the mtu configuration command also resets the MPLS MTU to HW MTU.

The behavior as described above was tested on a 3725 router running IOS release 12.4(15)T1. Although the MPLS MTU Command Changes document claims that you cannot set MPLS MTU larger than then interface MTU from IOS release 12.4(11)T, I was still able to do it in 12.4(15)T1.

Running OSPF across a firewall

When I was reading Joe Harris' post detailing how you can run OSPF across a PIX/ASA firewall (not with it, but between the adjacent routers), I wondered why anyone would want to do it. Our security gurus immediately gave me an answer: suppose you have two separate DMZs similar to the following setup:

You definitely don't want to attract traffic to a DMZ if the Internet uplink is down. One of the ways to handle it is to conditionally source the OSPF default route on the outside routers (based on availability of BGP prefixes, for example) and pass it to the inside routers that propagate it to the rest of the network.

The question that remains to be answered is “why wouldn't you run OSPF with the firewall?” If nothing else, if someone breaks into the outside router, he could manipulate the IP routing on the firewall, which is definitely not a good idea (you can't filter routing updates in OSPF like you can in RIP, EIGRP or BGP).

SNMP with Tcl

Looking from the outside, it looks like Tcl SNMP routines in Cisco IOS were designed by a commitee or came straight from Dilbert. The snmp_getone function that reads a single SNMP value does not return an array or a list (as one would expect), but a string representation of something that looks like an XML object (but is not, since its attributes are not properly quoted). As Tcl on Cisco IOS has no built-in XML support, parsing the return values is a pure joy (and a nice exercise in writing regular expressions).

The following excerpt of a telnet session shows how to extract a single SNMP value in Tcl (I've used extra steps and an interactive tclsh session for illustration purposes). The SNMP community has to be configured in advance with the snmp-server community test ro configuration command.

rtr#tclsh
rtr(tcl)#set value [snmp_getone test system.3.0]
{<obj oid='sysUpTime.0' val='14886'/>}
rtr(tcl)#regexp -inline {oid='(.*)'.*val='(.*)'} $value
{oid='sysUpTime.0' val='14886'} sysUpTime.0 14886
rtr(tcl)#regexp {oid='(.*)'.*val='(.*)'} $value ignore oid result
1
rtr(tcl)#puts $result
14886
And now for a complete example: the following script prints the router uptime.
#
# Simple Tcl script to print system uptime
#
set value [snmp_getone test system.3.0]
regexp {oid='(.*)'.*val='(.*)'} $value ignore oid result
set result [expr $result / 100]
puts "Router uptime is $result seconds"

War story: almost zero is not good enough

Some fifteen years ago we were building a router-based network using primarily baseband modems (that's how the DSL boxes with symmetrical speeds were called back then). Everything worked great, we even had DECnet running between a few sites. However, after a few weeks, a mystery phenomena crept up: when the users were copying files between two VAX computers, the link between the sites went down … always when copying the same file.

To make the long story short: every modem uses a predefined sequence that enables remote loopback. These sequences are standardized and have been chosen so that the chance of hitting them with real traffic is close to zero (but obviously not zero). The file that the users were trying to copy contained just the correct sequence to trigger the remote loopback in one of the modems and the link went down (most probably changed state to looped) as the routers started to receive their own packets. Disabling remote loopback on the modem (a jumper in those days) solved the problem.

The moral of the story: whenever you use pattern matching to identify something (be it a specific application that you're trying to identify or a virus in your workstation), there is a non-zero chance of false positives, usually in the most unusual places.

Let's conclude this post with what seems to me a ludicrous “invention”: someone patented the flashing of LEDs when performing loopback tests on a modem. If anyone can survive reading the whole patent application, understand it and recognize its true added value, please let me know … I got completely lost.

Advanced Routing and Switching for Field Engineers

The Advanced Routing and Switching for Field Engineers course was targeted primarily at Cisco partners, but it covers a variety of interesting technologies that anyone aiming past the CCNP level might benefit from. Apart from heavy focus on MPLS VPN (that was largely missing from the CCNP curriculum), it includes advanced network management and high availability topics.

If you're not an expert working for a Cisco partner, you'll probably not want to attend the full-blown instructor-led course, but you can still get the same hands-on experience using our newly released ARSFE remote lab exercises.

Turn your flash card into an ATA drive

The flash memory available in newer router platforms (at the very minimum the ISR routers and 37xx series) is capable of being used as a regular disk drive (for example, to store system logging information), but it might be formatted as a traditional Low-End File System (LEFS) flash card (more likely if the router was not manufactured recently). To change the flash card format to disk-like FAT32 format, use the format flash: privileged-level command (and don't forget to store the IOS image to another location before formatting the flash). After the format process is complete, you can create subdirectories on the flash: memory and use it as a regular disk device.A sample formatting operation is displayed below:

fw#format flash:
Format operation may take a while. Continue? [confirm]
Format operation will destroy all data in "flash:". Continue? [confirm]
Enter volume ID (up to 64 chars)[default flash]:
Current Low End File System flash card in flash will be formatted into DOS File System flash card!
Continue? [confirm] y

Format: Drive communication & 1st Sector Write OK...
Writing Monlib sectors.
........................................................
Monlib write complete

Format: All system sectors written. OK...

Format: Total sectors in formatted partition: 125297
Format: Total bytes in formatted partition: 64152064
Format: Operation completed successfully.

Format of flash complete

fw#show file system | include flash
* 64012288 27734016 disk rw flash:#

mturoute: trace mode output

Continuing from the previous mturoute-related post, this is how the mturoute utility behaves when you start it in traceroute mode (with the -t flag):

  • Similar to Windows tracert, it tries to find the successive hops in the path by sending ICMP echo packets with increasing values of TTL field.
  • Contrary to Cisco IOS and most Unix systems that send UDP packets to high-numbered ports, tracert uses ICMP echo packets.

  • For each router found in the path (= source IP address in the ICMP TTL exceeded message), mturoute tries to find path MTU to that hop using the same algorithm as in the ping mode.
  • During the bisecting phase, the mturoute does not print all the messages it prints in the ping mode, but just the cryptic signs (+/-/u/.) indicating its progress. Their meaning is documented in the previous post.
  • After the path MTU to the router under investigation is measured, mturoute reports the router's IP address and path MTU.
A sample trace-mode printout is included below:
$ mturoute -t 10.0.3.3
mturoute to 10.0.3.3, 30 hops max, variable sized packets
* ICMP Fragmentation is not permitted. *
* Maximum payload is 10000 bytes. *
 1 --+---+++-+++-++ host: 10.0.0.1 max: 1500 bytes
 2 --.u+---.u+.u+---u+.u+.u+ host: 10.2.0.2 max: 1476 bytes
 3 --+---+-+++++++ host: 10.0.3.3 max: 1472 bytes
The second hop in the printout has an inbound access-list that blocks incoming ICMP packets. The mturoute thus reports receiving ICMP unreachable ('u') as well as ping timeouts ('.') as not every incoming packet is replied to due to ICMP rate-limiting in Cisco IOS.

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

Display OSPF SPF tree

I did some double-checking of the ideas I wrote about in my EIGRP-to-OSPF migration article and accidentally typed show ip ospf route instead of show ip route ospf. The results were amazing: this undocumented command displays the per-area topology calculated by the SPF algorithm, including intra-area routes, inter-area routes, ABRs, ASBRs and external routes.A sample printout from one of my routers is included below:

POP#show ip ospf route
 
            OSPF Router with ID (10.1.0.3) (Process ID 1)
 
    Area 1
 
    Intra-area Route List
* 10.1.0.3/32, Intra, cost 1, area 1, Connected
      via 10.1.0.3, Loopback0
*> 10.1.0.17/32, Intra, cost 65, area 1
      via 10.7.1.1, Serial1/0
 
    Intra-area Router Path List
i 10.0.1.2 [64] via 10.7.1.5, Serial1/1, ABR, Area 1, SPF 3
i 10.0.1.1 [64] via 10.7.1.1, Serial1/0, ABR, Area 1, SPF 3
 
    Inter-area Route List
*> 10.0.1.2/32, Inter, cost 65, area 1
      via 10.7.1.5, Serial1/1
*> 10.0.5.2/32, Inter, cost 129, area 1
      via 10.7.1.5, Serial1/1
 
    Inter-area Router Path List
I 10.0.5.2 [128] via 10.7.1.5, Serial1/1, ASBR, Area 1, SPF 3
I 10.0.5.2 [164] via 10.7.1.1, Serial1/0, ASBR, Area 1, SPF 3
I 10.0.5.1 [128] via 10.7.1.1, Serial1/0, ASBR, Area 1, SPF 3
 
    External Route List
*> 0.0.0.0/0, Ext2, cost 20, tag 1
      via 10.7.1.1, Serial1/0
      via 10.7.1.5, Serial1/1

Display IP packet filters attached to router's interfaces

A few days ago, Jeremy Stretch asked me whether there's a command to display packet lists attached to router's interfaces. While he got pretty far with the output filters, he would like to have a nice tabular format as well as the contents of the access lists displayed next to the interfaces. The show ip access-list interface name command comes pretty close, but it displays the information only for a single interface, so it was time to write another Tcl script. To install it on your router:

  1. Download it from my web site and copy it to your router's flash or NVRAM.
  2. Define an alias, for example alias exec filters tclsh flash:packetFilters.tcl.

The script recognizes two parameters: the all parameter displays all interfaces, including ones with no access lists and the verbose parameter displays the contents of the access list after the interface name.

Here are a few sample printouts from one of my lab routers:
R2#filters
Interface Inbound Outbound
=========================================================
Serial1/0 101
Serial1/2 ICMP 101

R2#filters verbose

Serial1/0
====================
in: Extended IP access list 101
    10 permit ip any any (2012 matches)

Serial1/2
====================
in: Extended IP access list ICMP
    10 deny icmp any host 10.0.1.2 echo
    20 deny icmp any host 10.2.0.2 echo
    30 permit ip any any (637 matches)

out:Extended IP access list 101
    10 permit ip any any (2012 matches)

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

IOS 12.4T features summarized on one page

I always thought that the new format of the Cisco web-based documentation was awful, as it consumes way more bandwidth than the old version and is slower to load over low-speed links as it displays the text only after the complete page is loaded due to heavy use of table-based HTML layout (I will refrain from commenting the use of this layout technique in the third millenium). However, the new content structure has some significant benefits; for example, all the 12.4T feature guides are collected on a single page … fantastic if you try to find a feature that you remember was implemented somewhere in 12.4T track.

mturoute: ping-mode output

Jeff West has asked me to document the printout produced by the mturoute utility. Here's the first part of the documentation.

mturoute works in two modes:

  • Without the -t flag, it sends variable-lenght ICMP echo packets to the specified destination address, trying to figure out the largest packet that is successfully propagated to the destination.
  • With the -t flag, it uses traceroute-like algorithm to find the hop-by-hop IP addresses (the source IP addresses of the ICMP TTL exceeded replies) and uses the same packet-size-calculating algorithm to measure the path MTU to each hop.

Today we'll focus on the non-trace mode. It tries to measure the path MTU with a bisection method varying the packet sizes between minimum MTU (92) and maximum MTU (specified with the -m parameter, default is 10000 bytes). The payload size of the first packet (without the -m flag) is thus 5046 bytes ((10000 + 92)/2).

On each iteration, the algorithm prints a “cryptic” sign indicating whether the ping with the current payload size succeeded. The following indications are given:

  • '+': ICMP echo reply arrived
  • '-': The ping failed (for various reasons, including exceeding the path MTU)
  • 'u': ICMP destination unreachable response arrived, indicating blackhole or access-list.
  • ICMP unreachable is considered a successful response; at least we're measuring the path MTU up to the failure point

  • '.': timeout. The ping will be retried up to three times (or the number specified with the -r option).
In the ping mode, mturoute prints the current ICMP payload size at each step, resulting in a printout similar to the one below. If you'd have specified the -d option, the printout would include detailed status codes from the IcmpSendEcho function.
$ mturoute 10.0.3.3
* ICMP Fragmentation is not permitted. *
* Maximum payload is 10000 bytes. *
- ICMP payload of 5046 bytes failed..
- ICMP payload of 2569 bytes failed..
+ ICMP payload of 1330 bytes succeeded.
- ICMP payload of 1949 bytes failed..
- ICMP payload of 1639 bytes failed..
- ICMP payload of 1484 bytes failed..
+ ICMP payload of 1407 bytes succeeded.
- ICMP payload of 1445 bytes failed..
+ ICMP payload of 1426 bytes succeeded.
+ ICMP payload of 1435 bytes succeeded.
+ ICMP payload of 1440 bytes succeeded.
+ ICMP payload of 1442 bytes succeeded.
+ ICMP payload of 1443 bytes succeeded.
+ ICMP payload of 1444 bytes succeeded.
+ ICMP payload of 1444 bytes succeeded.
Path MTU: 1472 bytes.

Note: To use the debug-enabled version of mturoute, or the version that does not need VC++ runtime, download the new ZIP archive from my web site.

Change the routing protocol in your network

A while ago, one of my readers asked an interesting question: “are there any generic guidelines or steps to follow if you want to change the routing protocol in your network?” The October IP Corner article, Changing the Routing Protocol in Your Network, describes a potential scenario that you can apply to networks of medium complexity that have a single interior routing protocol and do not use two-way route redistribution.

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

Show IP access lists attached to an interface

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.For example, this is the printout from one of my test routers:

R2#show ip access-list 101
Extended IP access list 101
10 permit ip any any (1900 matches)
R2#show ip access-list interface tunnel 0
Extended IP access list ICMP in
10 deny icmp any host 10.0.1.2 echo
20 deny icmp any host 10.2.0.2 echo
30 permit ip any any (2279 matches)
Extended IP access list 101 out
10 permit ip any any (10 matches)

Log the NTP events

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 available from IOS release 12.3(7)T.For example, if you configure ...

rtr(config)#ntp logging
rtr(config)#ntp server 172.16.0.12
... the router will generate the following syslog messages when it synchronizes its time with the NTP server:
%NTP-6-RESTART: NTP process starts
%SYS-6-CLOCKUPDATE: System clock has been updated from 17:06:03 UTC Fri Mar 30 2007 to 17:04:07 UTC Fri Mar 30 2007, configured from NTP by 172.16.0.12.
%NTP-5-PEERSYNC: NTP synced to peer 172.16.0.12

OSPF router-id does not change when the interface IP address changes

The rules used to establish OSPF router ID on Cisco IOS are well known:

  • 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).

Most of these “wisdoms” are no longer true. For recent releases of Cisco IOS, OSPF router ID is a 32-bit value that has to be unique (that's all that the OSPF RFC ever asked for) and just happens to be taken from an interface address at the time the OSPF process is started. Even more, you can configure it to any value you like with the router-id A.B.C.D router configuration command.

The new behavior, while definitely making your network more stable, can also bring unexpected side effects: if you don't use the router-id command and misconfigure an interface IP address (resulting in duplicate router IDs), correcting the interface IP address will not fix the problem. You also have to reset the OSPF process with the clear ip ospf pid process command.

You cannot start a Telnet session from Tcl shell

Recently, I've got a really interesting question: “If I start a telnet or SSH session from my Tcl shell with the exec command, I get the initial text, but then it all freezes. What's wrong?”

Let's start with the basic picture: When you open a telnet session to a router, the input and output is captured by the Exec process. When you open an outgoing telnet or SSH session to another router, the Exec process implements the telnet/ssh client functionality and switches the input/output data between the two TCP sessions:However, when you start the Tcl shell, the Exec CLI loses its control of the input/output streams, as they are taken over by Tclsh. The only means of communicating with the Exec CLI is through the typeahead and exec commands:So, if you start another Telnet session with the exec command, the Tclsh still controls the input/output of the user session and there is no way for the telnet client in the Exec CLI to communicate with the user.

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