Designing Implementing an OSPF Network

Previous Table of Contents Next


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.


Figure 7-22  ASBRs consolidate routes.

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.


Figure 7-23  Manually configuring a path to the OSPF stub network.

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.


TIPS:  
You cannot tell OSPF to use a particular interface as its router ID. It has built in defaults that force it to accept a loopback interface first then the highest IP address on any interface.

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.


TIPS:  
Remember that OSPF will load balance over multiple equal-cost links, so if you use the defaults, this feature will be on automatically.

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:

  When they are exchanged for the first time.
  When a change occurs in the information they contain.

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 isn’t it.


Previous Table of Contents Next




OSPF Network Design Solutions
OSPF Network Design Solutions
ISBN: 1578700469
EAN: 2147483647
Year: 1998
Pages: 200
Authors: Tom Thomas

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net