According to the Cisco IOS documentation, you can select between the original and the universal CEF load sharing algorithm with the ip cef load-sharing algorithm name parameter global configuration command (we'll leave the tunnel algorithm aside for the moment). Of course, they don't tell you what you select.

The original algorithm used only the source and destination IP addresses to get the 4-bit hash entry (see the CEF Load Sharing Details for more information), which could result in suboptimal network utilization in some border cases (if anyone wants to know why, leave me a comment). The universal algorithm adds a router-specific value to the hash function, ensuring that the same source-destination pair will hash into a different 4-bit value on different boxes. If you really want to fine-tune the hash function, you can even specify the value to be added with the last option of the ip cef load-sharing algorithm command.

I had to investigate the details of CEF load sharing for one of my upcoming article and found (yet again) that the details are rather undocumented in official documentation. So, this is how it works (in case you ever need to know):

• For every CEF entry (IP route) where there are multiple paths to the destination, the router creates a 16-row hash table, populating the entries with pointers to individual paths. The hash table can be inspected with the show ip cef prefix internal command.
• The load balancing ratio is approxiated by number of entries in the hash table belonging to each path. If you have unequal-cost load balancing (EIGRP based on composite metrics and MPLS TE tunnels based on requested bandwidth), individual paths will be associated with different number of rows.
• If you configure per-destination load balancing, the source and destination IP address in the incoming IP packet are hashed into a 4-bit value that selects the outgoing path in the CEF has table.

These tips will help you get the most out of the Cisco IOS embedded web server:

• Home page for a Cisco IOS web server;
• Tar archives used by Cisco IOS web server;
• Multilevel web (HTTP) access to a router;
• Use command aliases to simplify Cisco IOS web server URLs;
• Include a default username/password in web request;
• Use Cisco IOS FTP server to bypass Microsoft "security patch".

If you give your users guest access to a router, you might want to disable some web-based applications the router usually offers (for example, command execution). To do this, use the following steps (first supported in IOS release 12.3(14)T, integrated in 12.4):

1. List all the web applications your Cisco IOS supports with the show ip http server session-module command. By default, all web applications should be active.
2. Create a subset of applications you want to activate with the ip http session-module-list list-name module-list. global configuration command, for example.

ip http session-module-list NoExec HTTP_IFS,HOME_PAGE,QDM,QDM_SA,XML_Api,EzVPN-Web-Intercept

3. Activate the desired applications with the ip http active-session-modules list-name configuration command (you should also use the ip http secure-active-session-modules command if you've enabled HTTPS server).
4. Verify the results with the show ip http server session-module command. Only the applications listed in your module list should be active, all others should be inactive.

I've got a great question related to a previous post:

Is there anyway to send the username and password with the URL request to the router so the user is not prompted for the login?

You can specify username and password as part of standard URL syntax http://username:password@host/rest-of-url, so to execute a show ip interface brief command you could use this URL (after configuring multilevel web access on the router):

http://guest:guest@router/level/1/exec/show/ip/interface/brief

Note: this syntax no longer works in Internet Explorer with latest security patches, please read http://support.microsoft.com/kb/834489 for more information on how to re-enable this behavior.

In some scenarios you want to use true username/password authentication when accessing the router's web server (by default, you have to use enable password). To change the HTTP authentication method, use the ip http authentication local configuration command; it tells the router to use local usernames and passwords when authentication web requests.

Before changing the HTTP authentication, you must define local usernames with the username username privilege-level level password password command, for example:

username guest privilege 1 password 0 guest
username admin privilege 15 password 0 admin

Note: unless you configure service password-encryption, the passwords in your configuration will remain in cleartext.

The last bit of the puzzle is the correct formation of the URLs: when executing a command on the router through a URL, you have to specify the required privilege level (the router will then prompt you for a username/password with at least that privilege level). The URL syntax is http://router/level/privilege-level/exec/command. For example, to execute non-privileged (level-1) show users command, use the following URL:

http://router/level/1/exec/show/users/CR

Note: the /CR suffix at the end of the URL tells the router to execute a command that contains optional (non-present) parameters.

If you have HTTP enabled on your router, you can use it to automate router reloads through web requests. To enable HTTP on the router, use the following commands:

ip http server
ip http access-class 90
access-list 90 permit network-management-ip-address

The ip http access-class configuration command is vital - it limits the access to the web server on your router to well-defined IP addresses.

The Visual Basic script to reload the router is extremely simple (just save the following lines into a file called reload.vbs):

Const RouterIP = "10.0.0.1" ' replace with router's IP address
Const EnablePassword = "password" ' replace with enable password

Set WebRq = CreateObject("MSXML2.XMLHTTP")
WebRq.Open "GET","http://" & RouterIP & "/level/15/exec/reload/CR",false,"Username",EnablePassword
WebRq.Send

And here is the equivalent PERL code for the open source community:

use LWP::UserAgent;

$routerIP = "10.0.0.1";
$enablePwd = "password";

$ua = LWP::UserAgent->new;
$req = HTTP::Request->new(GET => "http://$routerIP/level/15/exec/reload/CR");
$req->authorization_basic('', $enablePwd);
print $ua->request($req)->as_string;

By default, the username specified in the web request is ignored by the router and the password has to be the enable password. Of course, if you change the authentication scheme on the router with the ip http authentication configuration command, you'd use proper username/password pair in the HTTP request.

If you're still stuck with frame-relay connections (or use them in test environment, because it's easy to set up any-to-any connectivity between a larger number of routers), you were probably used to subinterface logging events reporting when the line protocol on a point-to-point subinterface would go up or down based on LMI DLCI status.

Very quietly, these logging events disappeared, first on 7500-series routers in IOS release 12.1(14), now they're gone by default on all platforms. If you still want to see what's going on with your frame-relay subinterfaces, you have to enter logging event subif-link-status configuration command on every subinterface.

I can only guess that some people that used the syslog events for network management were very surprised by the first (undetected) frame-relay failure following an IOS upgrade :)

Sometimes when using not-so-very stable IOS versions, periodic reload of a router during a non-peak (or idle) period is a good idea that can significantly increase the overall stability of your network. Until release 12.4, you had to write an external script that would log into the router and execute the reload command. With the Embedded Event Manager, the task is surprisingly simple - just enter the following configuration commands to reload the box every midnight (of course it helps if your router is NTP-synchronized to a reliable clock source and has correctly configured time zone).

event manager  applet Reload
 event timer cron name Reload cron-entry  "@midnight"
 action 1.0 reload

The @midnight is a predefined symbolic value for "0 0 * * *". Of course you can use any other value that the UNIX cron utility would recognize as valid first five fields (time specification; username and command line are obviously not used).

In IOS release 12.3, most Cisco routers can act as primary DNS servers (formerly, this functionality was only available as part of DistributedDirector product), alleviating the need for a host-based DNS server in your perimeter network. To configure a router to act as primary
DNS server for a zone, use the ip dns primary command, for example:

ip dns server
ip dns primary website.com soa ns.website.com
[email protected] 86400 3600 1209600 86400

Next, you need to define primary and secondary name servers for the domain.
Use the ip host ns command:

ip host website.com ns ns.website.com
ip host website.com ns ns.isp.com

You can also define mail routing for the domain with the ip host mx command:

ip host website.com mx 10 mail.website.com
ip host website.com mx 20 mail.isp.com

Finally, you need to define hosts within your domain (with the traditional form of the ip host command):

ip host ns.website.com 192.168.0.1 ! router's IP address
ip host www.website.com 192.168.1.1
ip host website.com 192.168.1.1 ! alternate for www.website.com
ip host mail.website.com 192.168.1.2

If you have HTTP server enabled on your router (on by default in many IOS releases, enable with ip http server), you can download the current router configuration into your web browser simply by typing in the URL http://router/exec/show/running/full. To get the startup configuration, use http://router/exec/show/startup-config/CR.

Of course, you need to authenticate to the router. By default, you can use anything as the username and the enable-password as the password, but you also use local usernames or AAA authentication. To use local usernames, configure ip http authentication local and enter username and password with the username username privilege 15 password password configuration command.

ip http client username web-user
ip http client password secret-password

With the ever-faster replacement of traditional WAN networks with MPLS VPN- or Internet-based solutions, it’s increasingly important to have a good design and implementation strategy for small multi-homed sites. While it’s easy to implement multi-homed sites whenever you can run a routing protocol between the customer edge (CE) and provider edge (PE) router, as is the case with most MPLS VPN implementations, the static default routing imposed on most Internet customers by their ISPs makes reliable multi-homing almost impossible in modern networks that are not able to signal loss of layer-2 connectivity reliably.

The Reliable Static Routing Using Object Tracking feature available in Cisco IOS release 12.4 allows you to tie static route viability to a tracked object (interface, another route …). If you track the state of the next-hop router, it’s possible to detect layer-3 failures reliably, triggering a reroute to the backup ISP. You can improve this design, track the end-to-end availability of the central site, and reroute to the backup ISP whenever you cannot reach the central site through the primary ISP. Even more, you don’t have to rely on ICMP echo packets; the IP SLA feature of Cisco IOS can track the availability of numerous applications (for example, your company’s central web server).

Using the design described in this article, you can implement fully redundant Internet connectivity without having an allocated public IP address space or autonomous system number. Even better, it’s completely static on the Internet side, thus alleviating the need to configure BGP on the gateway routers. However, the simplicity of the design brings a few drawbacks as well; you should use this design only in a stable environment where the switchover from primary to backup ISP is unlikely (but you still need the secondary connection to ensure reliability), as every switchover will cause all established TCP sessions to be terminated.

The article focused solely on the primary/backup scenario. While it is possible to extend it to support rudimentary load sharing, you have to be careful to ensure that all the IP packets between a pair of inside/outside hosts will always flow across the same gateway router (otherwise, the NAT configured on the gateway router will destroy the TCP session). Similarly, it’s possible (although not trivial) to implement publicly accessible inside servers; another article will cover this topic.

Numerous network devices can combine static routes with Bidirectional Forwarding Detection (BFD) and remove them from the routing table if the BFD session with the next-hop router fails. Unfortunately, that works only if the upstream network supports BFD on its customer-facing interfaces¹; we need a more generic solution that does not rely on the functionality of the upstream router².

Cisco IOS includes Enhanced Object Tracking functionality, which, together with Reliable Static Routing Using Object Tracking, solves the “Is the next hop reachable?” problem without relying on the adjacent router’s cooperation.

Enhanced Object Tracking introduces a generic track object that can track the state of an interface (layer-2 or layer-3 state), the presence or metric of an IP route, the state of an SLA measurement, or even the availability of Mobile IP home agent or GPRS nodes. You can also combine various track objects (including weighing them) into a compound object.

The Reliable Static Routing Using Object Tracking feature ties a track object to a static route – whenever the track object’s state is down, the static route is removed from the routing table; precisely what you would need to support reliable multi-homing. To configure a static route based on the state of the next-hop router, you need to:

• Configure an ip sla (previously known as Response Time Reporter – rtr) object pinging the next-hop router on the primary Internet link. The polling frequency you specify (in seconds) depends on the reliability requirements, but don’t exaggerate. Anything below a few seconds would unnecessarily burden the next-hop router (as you might not be the only one tracking its availability).

ip sla 100
 icmp-echo 172.16.1.2 source-interface GigabitEthernet0/2
 threshold 500
 timeout 1000
 frequency 3
ip sla schedule 100 life forever start-time now

• Create a track object monitoring the reachability of the SLA target.
• As you probably don’t want to respond to a single lost ICMP packet, you should use the delay option of the track object to specify how long the next-hop router should remain unreachable before it’s declared lost.
• The down delay should be at least three times the SLA polling frequency
• To deal with intermittent connectivity, the up delay should be even longer than the down delay. For example, a router can temporarily respond to pings while it boots.

track 100 ip sla 100 reachability
 delay down 10 up 20

• After configuring the track object, attach it to the primary static default route to ensure that the default route is removed if the next-hop router is not reachable:

ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/2 172.16.1.2 10 name ISP_A track 100
ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/3 172.17.3.2 251 name ISP_B_FB

You can check the proper operation of the reliable static routing with the show ip route command. The following listings display:

• The IP routing table on the GW router when the primary next-hop router is available
• The modified state of the IP routing table after the primary next-hop router failure.

gw#show ip route | begin Gateway
Gateway of last resort is 172.16.1.2 to network 0.0.0.0

S*    0.0.0.0/0 [10/0] via 172.16.1.2, GigabitEthernet0/2
      10.0.0.0/32 is subnetted, 1 subnets
C        10.0.0.1 is directly connected, Loopback0
      172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        172.16.1.0/30 is directly connected, GigabitEthernet0/2
L        172.16.1.1/32 is directly connected, GigabitEthernet0/2
      172.17.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        172.17.3.0/30 is directly connected, GigabitEthernet0/3
L        172.17.3.1/32 is directly connected, GigabitEthernet0/3
      192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.0.0/24 is directly connected, GigabitEthernet0/1
L        192.168.0.1/32 is directly connected, GigabitEthernet0/1

gw#show ip route | begin Gateway
Gateway of last resort is 172.17.3.2 to network 0.0.0.0

S*    0.0.0.0/0 [251/0] via 172.17.3.2, GigabitEthernet0/3
      10.0.0.0/32 is subnetted, 1 subnets
C        10.0.0.1 is directly connected, Loopback0
      172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        172.16.1.0/30 is directly connected, GigabitEthernet0/2
L        172.16.1.1/32 is directly connected, GigabitEthernet0/2
      172.17.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        172.17.3.0/30 is directly connected, GigabitEthernet0/3
L        172.17.3.1/32 is directly connected, GigabitEthernet0/3
      192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.0.0/24 is directly connected, GigabitEthernet0/1
L        192.168.0.1/32 is directly connected, GigabitEthernet0/1

Revision History

2025-03-31

• Mentioned BFD as an alternative to IP SLA
• Mentioned RFC 9747 as a potential BFD-based solution if the upstream router doesn’t want to participate in BFD (HT: Erik Auerswald)
• Recreated the router configurations and printouts with IOSv release 15.6(1)T.
• Added the command to shut down the PE_A interface when using netlab