Enhanced OSPF Adjacency Logging

The log-adjacency-changes OSPF configuration command was improved with the detail command that logs every step of OSPF adjacency establishment (sample printout below), making it a great troubleshooting tool.

%OSPF-5-ADJCHG: Process 1, Nbr 172.16.0.21 on Serial0/0/0.100 from DOWN to INIT, Received Hello
%OSPF-5-ADJCHG: Process 1, Nbr 172.16.0.21 on Serial0/0/0.100 from INIT to 2WAY, 2-Way Received
%OSPF-5-ADJCHG: Process 1, Nbr 172.16.0.21 on Serial0/0/0.100 from 2WAY to EXSTART, AdjOK?
%OSPF-5-ADJCHG: Process 1, Nbr 172.16.0.21 on Serial0/0/0.100 from EXSTART to EXCHANGE, Negotiation Done
%OSPF-5-ADJCHG: Process 1, Nbr 172.16.0.21 on Serial0/0/0.100 from EXCHANGE to LOADING, Exchange Done
%OSPF-5-ADJCHG: Process 1, Nbr 172.16.0.21 on Serial0/0/0.100 from LOADING to FULL, Loading Done
add comment

Disable console logging

Large amount of logging output (most often produced in a debugging process) sent to a router's console can significantly increase the router's CPU load and even stop the box from forwarding packets (high-end routers with distributed forwarding architecture are obviously an exception, but even they can lose routing adjacencies). The reason is very simple - console interrupt is one of the highest-priority interrupts on the router (otherwise you wouldn't be able to get a response to the BREAK key on a hung box).

Update January 9th 2007: The router does not check if a user is logged into the console port or a device (for example, a terminal) is attached to it; if console logging is enabled, messages are always sent to the console port (causing CPU load).

To stop the console logging, use the no logging console global configuration command (highly recommended for routers that are not usually accessed through the console port) or you might want to limit the amount of messages sent to the console with the logging console level configuration command (for example, logging console notifications).

Note: this article is part of You've asked for it series.
see 8 comments

"You've asked for it" series

Analyzing Google query strings that brought visitors to my blog (StatCounter is an excellent free tool to do this job), I usually find interesting (often repeating) queries that are not yet answered in my blog. Obviously there are not too many good answers on other web sites, otherwise Google users would probably not click on a hit on the second or third page (where my blog usually appears for more generic queries).

So, to help my fellow networking engineers, I've decided to start a series of "You've asked for it" articles answering the questions that brought many of you to my site in the first place (and, don't forget, you can always send me an interesting question with the Send a message link on my bio page.
see 3 comments

Remove timestamps from syslog messages

The ability to replace router uptime with date and time in the logging messages with the service timestamps log datetime command was present in IOS for a long time, but I was always annoyed at timestamps when collecting syslog messages for demonstration purposes. The command to turn them off has also been available "forever", but was too obvious for me to try out ... the no service timestamps log command.
see 4 comments

Per-destination or per-packet CEF load sharing?

Cisco Express Forwarding (CEF) can perform per-packet or per-destination (actually source/destination IP address pair) load-sharing with no performance degradation (without CEF, per-packet load-sharing requires process switching). Even though there is no performance impact on the router, per-packet load sharing will almost always result in out-of-order packets. The packet reordering might degrade TCP throughput in high-speed environments (in low-speed/few-flows scenarios, per-packet load-sharing actually improves the per-flow throughput) or severely impact applications that cannot survive out-of-order packet delivery, such as Fast Sequenced Transport for SNA over IP or voice/video streams.

To configure per-packet load-sharing, use the ip load-sharing per-packet interface configuration command (default is per-destination). This command has to be configured on all outgoing interfaces over which the traffic is load-shared.

The switch between the load-sharing modes is not immediate; sometimes you have to wait a few seconds for the ip load-sharing command to take effect, worst case a manual clearing of the CEF table (clear ip cef address) is required.

see 10 comments

Configuration Change Logging ignores the configuration downloads

The Configuration Change Notification and Logging feature is supposed to log changes to the router's configuration. While it does a great job of logging commands entered in the router configuration mode, it completely ignores configuration changes due to configuration download (for example, with configure network or copy tftp running-config command).
read more add comment

Local username authentication

As I get a lot of hits from Google refering to local login, here's the whole story: Cisco IOS supports local username/password based authentication (almost) forever (it's been there even before the AAA architecture). To change from simple password-based authentication to username+password based on, use login local configuration command on console and/or VTY lines. The local usernames and passwords are defined with the username configuration command.
read more add comment

Cisco IOS violates RFC 2616 (HTTP/1.1)

Update 2012-08-27: Stefan de Kooter reported the bug had been fixed in IOS release 15.1(4)M.

I simply had to check with the RFC; by setting the Host: field of HTTP request to an IP address (instead of a host name), Cisco IOS violates section 14.23 of RFC 2616, which says:

The Host request-header field specifies the Internet host and port number of the resource being requested, as obtained from the original URI given by the user or referring resource ... The Host field value MUST represent the naming authority of the origin server or gateway given by the original URL.
add comment

IOS HTTP client sets Host: field to IP address

Update 2012-08-27: Stefan de Kooter reported the bug had been fixed in IOS release 15.1(4)M.

If you run multiple web sites on a single physical server, it's highly likely that you rely on the ability of HTTP/1.1 clients to specify the Host: field in the HTTP request to indicate which web site they're trying to access.

Cisco IOS always inserts the web server's IP address (not the hostname) in the Host: field of the HTTP request, regardless of whether you enter IP address or hostname in the URL part of an IOS command that supports HTTP (for example, copy or more command) ... and regardless of whether the hostname is locally configured with the ip host command or resolved by an external DNS server specified in the ip name-server command.

End result: Cisco IOS-based routers (tested up to release 12.4(11)T) can access only the default web site on a web server hosting multiple web sites.

add comment
Sidebar