Generating a Default OSPF Route during Redistribution
Whenever you specifically configure redistribution of routes from a different routing protocol or autonomous system into an OSPF routing domain, the router in question automatically becomes an autonomous system boundary router (ASBR) because it is doing the redistribution. You can force an ASBR to generate a default route into an OSPF routing domain as illustrated in Figure 7.22.
However, an ASBR does not, by default, generate a default route into the OSPF routing domain. To force the ASBR to generate a default route, perform the following task in router configuration mode:
default-information originate [always] [metric metricvalue] [metric-typetype-value] [route-map map-name]
Figure 7-23 shows a good example of when you would generate a default during the use of an OSPF stub area.
The most common method of generating a default route is through the use of a static route statement within the router. When using a static route paired with a passive interface, you will stop routing updates and enable the path to have a lower administrative distance.
Configuring Lookup of DNS Names
You can configure OSPF to look up Domain Naming System (DNS) names for use in all OSPF show command displays. This feature makes it easier to identify a router, because it is displayed by name rather than by its router ID or neighbor ID. Through the use of this command you will find that some of the more cryptic components displayed by OSPF will make a bit more sense, especially if you have used a good naming system, as previously discussed.
To configure OSPF to do a DNS name lookup, perform the following task in the routers global configuration mode:
ip ospf name-lookup
Forcing the Router ID Choice with a Loopback Interface
OSPF uses the largest IP address configured on the interfaces as its router ID. If the interface associated with this IP address is ever unavailable, or if the address is removed, the OSPF process must recalculate a new router ID and flood all its routing information out its interfaces.
If a loopback interface is configured with an IP address, OSPF will default to using this IP address as its router ID, even if other interfaces have larger IP addresses. Because loopback interfaces never go down, greater stability throughout your OSPF network is achieved.
Disable Default OSPF Metric Calculation Based on Bandwidth
In Cisco IOS Release 10.2 and earlier, OSPF assigned default metrics to router interfaces regardless of the interface bandwidth. It gave both 64K and T1 links the same metric (1562), and thus required an explicit ip ospf cost command in order to take advantage of the faster link.
In Cisco IOS Release 10.3 and later, by default, OSPF calculates the OSPF metric for an interface according to the bandwidth statement of the interface. You can see this in the following excerpt from a router:
OSPF_Router# sho int s0 Serial0 is down, line protocol is down Hardware is QUICC Serial (with onboard CSU/DSU) Description: OSPF uses the Bandwidth Statement on EVERY Interface Internet address is 10.251.20.1/24 MTU 1500 bytes, BW 56 Kbit, DLY 20000 usec, rely 255/255, load 1/255 Encapsulation FRAME-RELAY IETF, loopback not set, keepalive set (10 sec) LMI enq sent 0, LMI stat recvd 0, LMI upd recvd 0, DTE LMI down LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0 LMI DLCI 0 LMI type is ANSI Annex D frame relay DTE Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 0 Last input never, output never, output hang never Last clearing of "show interface" counters 00:02:17 Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 0 packets input, 0 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 0 packets output, 0 bytes, 0 underruns 0 output errors, 0 collisions, 5 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions DCD=down DSR=down DTR=up RTS=up CTS=up
For example, a 64K link gets a metric of 1562, and a T1 link gets a metric of 64.
To disable this feature, perform the following task in router configuration mode:
no ospf auto-cost-determination
Configuring OSPF Over On-Demand Circuits
The OSPF on-demand circuit operational capability is an enhancement to the OSPF protocol that allows efficient operation over on-demand circuits like ISDN, X.25, switched virtual circuits (SVCs) and dial-up lines. This feature set is fully supported by Cisco and follows the standard as described in RFC 1793, Extending OSPF to Support Demand Circuits. This is one of the better RFCs and is worth consulting if you plan to configure OSPF to operate within this type of networking environment.
Prior to this RFC, periodic OSPF hello and link-state advertisements (LSAs) would be exchanged between routers that were connected on the demand link, even when no changes were being reported in the hello or LSA information. This would cause the costs involved with these types of connectivity to skyrocket.
However, with this enhancement to OSPF, periodic hellos are suppressed and the periodic refreshes of LSAs are not flooded over the demand circuit. These packets bring up the link only under tightly controlled circumstances:
This operation allows the underlying Data Link layer to be closed when the network topology is stable. Thus saving on unnecessary costs. This is very useful because if your company is paying ISDN costs every time a call is placed, you want to ensure that the call is necessary. Consider it an automatic feature that restricts your teenage daughter from using the telephone unless it is necessary . . . very useful isnt it.