This is the follow up discussion for the post titled, "Have you seen my Router ID?"

The underlying issue here was trying to get OSPF to bypass the usual selection process for Router ID. The normal selection order is:

Manual router ID configured under ospf process
Highest IP address of a loopback in the up state in the respective routing table
Highest IP address of an interface of an up state in the respective routing table

If there are no up interfaces and you have not manually configured a router ID, you will get an error when you try to configure an OSPF process.

In general, most solutions focused around either using the OSPF selection process to one's advantage, or trying to "hide" the loopback from OSPF, so that it would select something else.

Some solutions were flat out wrong, because they broke the section requirements (mostly either configuring a router-id, or shutting down a loopback interface. Be sure to read the lab requirements carefully.

Solutions that didn't work (at least on the versions that I tested)

Backup interface
The idea being that the interface is down, and will not be assigned out as a router ID. This worked fine initially, but the router grabbed the (wrong) address after a reload, violating the requirement of functionality after the reload.

Interface Dampening with a restart penalty
The idea here was presumably that the interface would start off dampened, and not be selected as the router ID. After a reload, the interface did indeed show as dampened, but the interface was still up, and was chosen as the router ID.

Solutions that worked:

Easiest / most common answer:

Two OSPF routing processes

If there are two processes configured on the router, the highest loopback will be assigned to the first one CONFIGURED, and the second highest loopback will be assigned to the second process. The first process doesn't have to have any networks assigned, nor does it need to have a process number numerically smaller than the second process.

More complex:

One or more VRFs, possibly with secondary addresses.

Instructor Favorite (of the proposed solutions):

Kron scheduling to kick off a EEM applet when the router reloads to "no shut" the loopback interface. Since the loopback starts off shutdown, the OSPF process doesn't use it, and grabs the other one. The EEM applet runs, enabling the loopback, allowing the networks to be advertised properly to the neighbor. Although this configuration did include the loopback being shutdown, it was only shutdown for a brief period of time while the device was loading.

(Note: Scott Morris laughed out loud when informed of this one.)