Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
With EIGRP, neighborship is relatively simple. If two EIGRP routers discover each other
(using Hellos) and meet several requirements (like being in the same subnet), the two
routers become neighbors. After becoming neighbors, the two EIGRP routers exchange
topology information.
Key
Topic
Table 5-4 OSPF Feature Summary
Feature Description
Transport IP, protocol type 89 (does not use UDP or TCP).
Metric Based on cumulative cost of all outgoing interfaces in a route.
The interface cost defaults to a function of interface bandwidth
but can be set explicitly.
Hello interval Interval at which a router sends OSPF Hello messages on an interface.
Dead interval Timer used to determine when a neighboring router has failed,
based on a router not receiving any OSPF messages, including
Hellos, in this timer period.
Update destination address Normally sent to 224.0.0.5 (All SPF Routers) and 225.0.0.6 (All
Designated Routers).
Full or partial updates Full updates are used when new neighbors are discovered; otherwise,
partial updates are used.
Authentication Supports MD5 and clear-text authentication.
VLSM/classless OSPF includes the mask with each route, also allowing it to
support discontiguous networks and VLSM.
Route Tags Allows OSPF to tag routes as they are redistributed into OSPF.
Next-hop field Supports the advertisement of routes with a different next-hop
router than the advertising router.
Manual route summarization Allows route summarization at ABR routers only.
www.CareerCert.info
150 CCNP ROUTE 642-902 Official Certification Guide
Comparing OSPF and EIGRP, OSPF neighborship is more complex. First, with EIGRP, two
routers either become neighbors or they do not. With OSPF, even after all the neighbor
parameter checks pass, two classes of neighborships exist: neighbors and fully adjacent
neighbors. The OSPF neighbor discovery process has many pitfalls when the internetwork
uses Frame Relay, with a class of issues that simply do not exist with EIGRP. Finally, OSPF
uses an underlying Finite State Machine (FSM) with eight neighbor states used to describe
the current state of each OSPF neighbor, adding another layer of complexity compared
to EIGRP.
This section breaks down the OSPF neighbor relationship, the logic, and the OSPF configuration
settings–anything that impacts OSPF neighborship on LAN interfaces. In particular,
this section examines the following questions:
■ On what interfaces will this router attempt to discover neighbors by sending multicast
OSPF Hello messages?
■ When a potential neighbor is discovered, do they meet all requirements to become
neighbors at all?
This section examines these topics, in sequence.
Enabling OSPF Neighbor Discovery on LANs
OSPF sends multicast OSPF Hello messages on LAN interfaces, attempting to discover
OSPF neighbors, when two requirements are met:
■ OSPF has been enabled on the interface, either through the network router subcommand
or the ip ospf area interface subcommand.
■ The interface has not been made passive by the passive-interface router subcommand.
When both requirements are met, OSPF sends Hellos to the 224.0.0.5 multicast address, an
address reserved for all OSPF-speaking routers. The Hello itself contains several parameters
that must be checked, including the OSPF RID of the router sending the Hello, and
the OSPF area that router has assigned to that LAN subnet.
Of the three configuration commands that might impact whether a router attempts to discover
potential neighbors on an interface, one is commonly understood (network) and was
already covered in this chapter’s “OSPF Configuration Review” section. The second configuration
command that impacts whether potential neighbors discover each other,
passive-interface, works just like it does with EIGRP. In short, when a router configures an
interface as passive to OSPF, OSPF quits sending OSPF Hellos, so the router will not discover
neighbors. The router will still advertise about the interface’s connected subnet if
OSPF is enabled on the interface, but all other OSPF processing on the interface is
stopped.
The third configuration command that impacts whether a router discovers potential neighbors
using Hellos is the ip ospf process-id area area-id interface subcommand. This command
acts as a replacement for the OSPF network command. Simply put, this command
enables OSPF directly on the interface and assigns the area number.
Key
Topic
www.CareerCert.info
Chapter 5: OSPF Overview and Neighbor Relationships 151
To demonstrate the ip ospf area and passive-interface commands, Example 5-3 shows a
revised configuration on Router R3 as seen originally back in Example 5-1. In this new example
configuration, R3 has made two interfaces passive, because no other OSPF routers
exist on its LAN subnets–making any attempt to discover OSPF neighbors have no benefit.
Additionally, R3 has migrated its configuration away from the older network commands,
instead using the ip ospf area interface subcommand.
Example 5-3 Configuring passive-interface and ip ospf area
Interface loopback 1
Ip address 3.3.3.3 255.255.255.255
router ospf 3
passive-interface FastEthernet0/0
passive-interface FastEthernet0/1
interface FastEthernet0/0
ip ospf 3 area 0
interface FastEthernet0/1
ip ospf 3 area 0
interface Serial0/0/1
ip ospf 3 area 0
R3#show ip protocols
Routing Protocol is “ospf 3”
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID 3.3.3.3
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Maximum path: 4
Routing for Networks:
Routing on Interfaces Configured Explicitly (Area 0):
Serial0/0/1
FastEthernet0/1
FastEthernet0/0
Reference bandwidth unit is 100 mbps
Passive Interface(s):
FastEthernet0/0
FastEthernet0/1
Routing Information Sources:
Gateway Distance Last Update
Distance: (default is 110)
Note that in the second half of Example 5-3 the show ip protocols command now lists the
interfaces as matched with the ip ospf area commands, and it lists the passive interfaces.
You can take the list of explicitly configured interfaces, remove the passive interfaces, and
know which interfaces on which R3 will attempt to discover OSPF neighbors. Also, take a
www.CareerCert.info
152 CCNP ROUTE 642-902 Official Certification Guide
moment to compare this output with the same command’s output in Example 5-2, with
the earlier example listing the parameters of the configured network commands.
Settings That Must Match for OSPF Neighborship
After an OSPF router has discovered a potential neighbor by receiving a Hello from the
other router, the local router considers the router that sent the Hello as a potential neighbor.
The local router must examine the contents of the received Hello, plus a few other
factors, compare those settings to its own, check for agreement, and only then may that
other router be considered an OSPF neighbor.
For reference, the following list details the items seen in OSPF Hello messages. Note that
some fields might not be present in a Hello, depending on the conditions in the network.
■ OSPF Router ID
■ Stub area flag
■ Plus the following interface-specific settings:
■ Hello interval
■ Dead Interval
■ Subnet mask
■ List of neighbors reachable on the interface
■ Area ID
■ Router priority
■ Designated Router (DR) IP address
■ Backup DR (BDR) IP address
■ Authentication digest
Table 5-5 summarizes the items that two routers will compare when deciding whether they
can become OSPF neighbors. For study purposes, the table also lists some items that one
might think prevent OSPF neighborship but do not, with comparisons to EIGRP.
Key
Topic
Table 5-5 Neighbor Requirements for EIGRP and OSPF
Requirement OSPF EIGRP
Interfaces’ primary IP addresses must be in same subnet.
Yes Yes
Must not be passive on the connected interface. Yes Yes
Must be in same area. Yes N/A
Hello interval/timer, plus either the Hold (EIGRP) or
Dead (OSPF) timer, must match.
Yes No
Router IDs must be unique. Yes No
IP MTU must match. Yes1 No
www.CareerCert.info
Chapter 5: OSPF Overview and Neighbor Relationships 153
Note: Table 5-5 repeats most of the information listed in Chapter 2, Table 2-4, but in an
order that focuses on OSPF issues.
The first few items in Table 5-5 require only a minor amount of discussion. First, OSPF
checks the IP address (found as the source address of the Hello message) and mask (listed
in the Hello message) of the potential neighbor, calculates the subnet number, and compares
the subnet number and mask to its own interface IP address. Both the subnet number
and mask must match. Additionally, the OSPF Hello messages include the area
number on the subnet, as defined by that router. The receiving router compares the received
Hello with its own configuration and rejects the potential neighbor if the area numbers
do not match.
The next several headings inside this section examine the other three settings that can
prevent OSPF neighborship: Hello and Dead intervals, OSPF Router ID, IP MTU, and
authentication.
Optimizing Convergence Using Hello and Dead Timers
Using the same concept as EIGRP, but with different terminology, OSPF uses two timers
to monitor the reachability of neighbors. With OSPF, the Hello interval defines how often
the router sends a Hello on the interface. The Dead interval defines how long a router
should wait, without hearing any Hello messages from that neighbor, before deciding that
the neighbor failed. For example, with a default LAN interface setting of Hello of 10, and
Dead of 40, the local router sends Hello messages every 10 seconds. The neighbor resets
its downward-counting Hold timer to 40 upon receiving a Hello from that neighbor. Under
normal operation on a LAN, with defaults, the Dead timer for a neighbor would vary from
40, down to 30, and then be reset to 40 upon receipt of the next Hello. However, if the
Hello messages were no longer received for 40 seconds, the neighborship would fail, driving
convergence.
To tune for faster convergence, you can configure OSPF to set a lower Hello and Dead
timer. It speeds convergence in some cases; note that if the interface fails, OSPF will immediately
realize that all neighbors reached through that interface have also failed and not
wait on the Dead timer to count down to zero. For example, consider the internetwork in
Figure 5-4. This internetwork has four routers connected to the same VLAN, with the interfaces,
IP addresses, masks, and OSPF areas as shown.
Example 5-4 verifies some of the facts about the routers in Figure 5-4, showing the
changes to the Hello interval and the resulting failed neighborships. Each router has been
assigned an obvious RID: 1.1.1.1 for R1, 2.2.2.2 for R2, and so on.
Example 5-4 The Effect of Configuring a Different OSPF Hello Interval
R4#show ip ospf neighbors
Neighbor ID Pri State Dead Time Address Interface
1.1.1.1 1 2WAY/DROTHER 00:00:35 10.5.5.1
FastEthernet0/0
2.2.2.2 1 FULL/BDR 00:00:39 10.5.5.2
FastEthernet0/0
3.3.3.3 1 FULL/DR 00:00:38 10.5.5.3
FastEthernet0/0
R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#interface fastethernet0/0
R4(config-if)#ip ospf hello-interval 9
R4(config-if)#^Z
*Apr 28 00:06:20.271: %SYS-5-CONFIG_I: Configured from console by console
R4#show ip ospf interface fa0/0
FastEthernet0/0 is up, line protocol is up
Chapter 5: OSPF Overview and Neighbor Relationships 155
Internet Address 10.5.5.4/28, Area 0
Process ID 4, Router ID 4.4.4.4, Network Type BROADCAST, Cost: 1
Enabled by interface config, including secondary ip addresses
Transmit Delay is 1 sec, State DROTHER, Priority 1
Designated Router (ID) 3.3.3.3, Interface address 10.5.5.3
Backup Designated router (ID) 2.2.2.2, Interface address 10.5.5.2
Timer intervals configured, Hello 9, Dead 36, Wait 36, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:01
Supports Link-local Signaling (LLS)
Index 1/1, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 0, maximum is 3
Last flood scan time is 0 msec, maximum is 4 msec
Neighbor Count is 3, Adjacent neighbor count is 2
Adjacent with neighbor 2.2.2.2 (Backup Designated Router)
Adjacent with neighbor 3.3.3.3 (Designated Router)
Suppress hello for 0 neighbor(s)
R4#
*Apr 28 00:06:51.559: %OSPF-5-ADJCHG: Process 4, Nbr 1.1.1.1 on FastEthernet0/0
from 2WAY to DOWN, Neighbor Down: Dead timer expired
*Apr 28 00:06:57.183: %OSPF-5-ADJCHG: Process 4, Nbr 3.3.3.3 on FastEthernet0/0
from FULL to DOWN, Neighbor Down: Dead timer expired
*Apr 28 00:06:58.495: %OSPF-5-ADJCHG: Process 4, Nbr 2.2.2.2 on FastEthernet0/0
from FULL to DOWN, Neighbor Down: Dead timer expired
This example demonstrates several interesting facts. First, note that upon configuring the
ip ospf hello-interval 9 command under Fa0/0, the show ip ospf interface fa0/0 command
shows that not only did the Hello interval change, but the Dead timer was set to 4X
the Hello interval, or 36. To directly set the Dead timer on the interface, use the ip ospf
dead-interval value interface subcommand. Then, at the end of the example, note that all
three of R4’s neighbor relationships failed, because those routers now have mismatched
Hello and Dead timers. However, the neighbor relationships failed only after the dead
timers expired, as noted in the messages, and as confirmed by the timestamps on the messages.
Example 5-4 also shows the two normal, stable, and working neighbor states. Look to the
heading “state” in the output of the show ip ospf neighbors command at the top of the
example. The first word (before the /) lists the state or status of each neighbor. FULL refers
to a fully adjacent neighbor, meaning the OSPF topology has been fully exchanged with
that neighbor. The other state listed there, 2WAY, is a normal, stable, working state for
neighbors with which topology data was not exchanged directly. As described in Chapter
6, in some cases OSPF routers exchange their topology information to one specific router
on a LAN, called the designated router (DR), but they do not exchange their database directly
with other routers. In the preceding example, taken from R4, R4 lists its relationship
with R1 as 2WAY, which happens to be the status for a working neighbor that does not become
fully adjacent.
www.CareerCert.info
156 CCNP ROUTE 642-902 Official Certification Guide
Chapter 6’s section “Exchange with a Designated Router” discusses the database exchange
process when using a DR.
Note: OSPF has two methods to tune the Hello and Dead intervals to subsecond values.
Like EIGRP, OSPF supports Bidirectional Forwarding Detection (BFD). Additionally, OSPF
supports command ip ospf dead-interval minimal hello-multiplier multiplier, which sets
the dead interval to one second, and the Hello interval to a fraction of a second based on
the multiplier. For example, the command ip ospf dead-interval minimal hello-multiplier 4
sets the dead interval to one second, with Hellos occurring four times (the multiple) per
second, for an effective Hello interval of ¼ seconds.
Using a Unique OSPF Router-ID
As mentioned earlier in the “OSPF CCNA Review” section, each OSPF router assigns itself
a router ID, based on the same rules as EIGRP. In OSPF’s case, that means a router
first looks for the OSPF router-id rid-value OSPF subcommand; next, to the highest IP
address of any up/up loopback interface; and finally, to the highest IP address of any
up/up non-loopback interface.
An OSPF RID mismatch makes for unpredictable results because OSPF routers base their
view of the topology on the topology database, and the database identifies routers based
on their RIDs. By design, all OSPF RIDs in a domain should be unique; to avoid such issues,
OSPF prevents neighborships between routers with duplicate RIDs.
The next example shows what happens when two routers discover each other as potential
neighbors, but notice a duplicate RID. Using the same network as in Figure 5-4, each
router has been assigned an obvious RID: 1.1.1.1 for R1, 2.2.2.2 for R2, and so on. Unfortunately,
R4 has been mistakenly configured with RID 1.1.1.1, duplicating R1’s RID. R4 is
powered on after all three other routers have established neighbor relationships. Example
5-5 shows some of the results.
Example 5-5 OSPF RID Mismatch – R1 and R4, R4 Connects after R1
! On R1... the following output occurs AFTER R4 powers on. R1, RID 1.1.1.1,
! does not form a neighbor relationship with R4.
R1#show ip ospf neighbors
Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 1 FULL/BDR 00:00:35 10.5.5.2
FastEthernet0/0
3.3.3.3 1 FULL/DR 00:00:33 10.5.5.3
FastEthernet0/0
! On R3
! R3 does form a neighbor relationship, but does not learn routes from the
! R4. Note that R3 does not have a route for R4’s 10.4.4.0/27 subnet.
www.CareerCert.info
Chapter 5: OSPF Overview and Neighbor Relationships 157
R3#show ip ospf neighbors
Neighbor ID Pri State Dead Time Address Interface
1.1.1.1 1 FULL/DROTHER 00:00:38 10.5.5.1
FastEthernet0/0
1.1.1.1 1 FULL/DROTHER 00:00:37 10.5.5.4
FastEthernet0/0
2.2.2.2 1 FULL/BDR 00:00:35 10.5.5.2
FastEthernet0/0
R3#show ip route ospf
10.0.0.0/8 is variably subnetted, 4 subnets, 4 masks
O 10.2.2.0/25 [110/2] via 10.5.5.2, 00:06:56, FastEthernet0/0
O 10.1.1.0/24 [110/2] via 10.5.5.1, 00:01:34, FastEthernet0/0
As you can see from the output on R1, whose RID is duplicated with R4, the routers with
duplicate RIDs do not form a neighbor relationship. Additionally, other routers, such as
R3 as shown in the example, do form a neighbor relationship with the two routers, but the
duplication confuses the topology flooding process. Because R3 formed its neighborship
with R1 before R4, R3 does learn a route for R1’s 10.1.1.0/24 subnet, but does not for R4’s
10.4.4.0/27 subnet. However, with the same configuration, but a different sequence and
timing of neighbors coming up, R3 might learn about 10.4.4.0/27 instead of 10.1.1.0/24.
Note: Note that the OSPF process will not start without an RID.
Using the Same IP MTU
The maximum transmission unit (MTU) of an interface tells IOS the largest IP packet that
can be forwarded out the interface. This setting protects the packet from being discarded
on data links whose Layer 2 features will not pass a frame over a certain size. For example,
routers typically default to an IP MTU of 1500 bytes to accommodate Ethernet’s rules
about frames not exceeding 1526 bytes.
From a data plane perspective, when a router needs to forward a packet larger than the
outgoing interface’s MTU, the router either fragments the packet or discards it. If the IP
header’s don’t fragment (DF) bit is set, the router discards the packet. If the DF bit is not
set, the router can perform Layer 3 fragmentation on the packet, creating two (or more) IP
packets with mostly identical IP headers, spreading the data that follows the original IP
packet header out among the fragments. The fragments can then be forwarded, with the
reassembly process being performed by the receiving host.
From a design perspective, the MTU used by all devices attached to the same data link
ought to be the same value. However, routers have no dynamic mechanism to prevent the
misconfiguration of MTU on neighboring routers.
When an MTU mismatch occurs between two OSPF neighbors, one router will attempt to
become neighbors with the other router whose MTU differs. The other router will be
listed in the list of neighbors (show ip ospf neighbor). However, the two routers will not
www.CareerCert.info
158 CCNP ROUTE 642-902 Official Certification Guide
exchange topology information, and the two routers will not calculate routes that use this
neighbor as the next-hop router.
The IP MTU can be set on an interface using the ip mtu value interface subcommand and
for all Layer 3 protocols with the mtu value interface subcommand. Example 5-6 shows
an example, with R4 again configured so that it has problems.
Example 5-6 Setting IP MTU and Failing the OSPF Database Exchange Process
R4#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#int fastethernet0/0
R4(config-if)#ip mtu 1498
R4(config-if)#^Z
R4#
R4#show ip interface fa0/0
FastEthernet0/0 is up, line protocol is up
Internet address is 10.5.5.4/28
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1498 bytes
! lines omitted for brevity
R4#show ip ospf neighbors
Neighbor ID Pri State Dead Time Address Interface
1.1.1.1 1 EXSTART/DROTHER 00:00:39 10.5.5.1
FastEthernet0/0
2.2.2.2 1 EXSTART/DROTHER 00:00:37 10.5.5.2
FastEthernet0/0
3.3.3.3 1 EXSTART/BDR 00:00:39 10.5.5.3
FastEthernet0/0
*Apr 28 12:36:00.231: %OSPF-5-ADJCHG: Process 4, Nbr 2.2.2.2 on FastEthernet0/0
from EXSTART to DOWN, Neighbor Down: Too many retransmissions
R4#show ip ospf neighbors
Neighbor ID Pri State Dead Time Address Interface
1.1.1.1 1 INIT/DROTHER 00:00:39 10.5.5.1
FastEthernet0/0
2.2.2.2 1 DOWN/DROTHER - 10.5.5.2
FastEthernet0/0
3.3.3.3 1 INIT/DROTHER 00:00:39 10.5.5.3 FastEthernet0/0
Note that you could argue that the mismatched MTU does not prevent routers from becoming
neighbors, but it does prevent them from successfully exchanging topology data.
When the mismatch occurs, a pair of routers tries to become neighbors, and they list each
other in the output of show ip ospf neighbors, as seen in Example 5-6. However, the
neighbor state (listed before the /, under heading “State”) moves from EXSTART (which
means the database exchange process is starting), but it fails as implied by the highlighted
www.CareerCert.info
Chapter 5: OSPF Overview and Neighbor Relationships 159
message in the example. Then, the state changes to DOWN, and later one router tries
again, moving to INIT (initializing) state. So, the neighbor is listed in the output of show
ip ospf neighbors command, but never succeeds at exchanging the topology data.
Chapter 6 discusses the database exchange process, making reference to neighbor states.
Table 6-5, in Chapter 6s section “OSPF Message and Neighbor State Reference,” summarizes
the neighbor state values and their meaning.
OSPF Authentication
OSPF authentication causes routers to authenticate every OSPF message. To do so, the
routers use the same preshared key value, generating an MD5 digest for each OSPF message
and sending that digest as part of each OSPF message. If a router configured for
OSPF authentication receives an OSPF message, and the received message’s MD5 digest
does not pass the authentication checking based on the local key value, the router silently
discards the message. As a result, when authentication fails, two routers cannot become
OSPF neighbors, because they ignore the inauthentic OSPF Hello messages.
OSPF authentication uses one of three types: type 0 (no authentication), type 1 (clear
text), and type 2 (MD5), with MD5 being the only reasonable option in production networks.
To configure to have no authentication, do nothing, because IOS defaults to not attempt
OSPF authentication. However, for either of the other two OSPF authentication
options, you need to follow two configuration steps, as follows:
Step 1. Authentication must be enabled, plus the authentication type must be selected,
through one of two means:
Enabling per interface using the ip ospf authentication [message-digest] interface
subcommand
Enabling on all interfaces in an area by changing the area-wide authentication
setting using the area area-no authentication [message-digest] subcommand
under router ospf
Step 2. The authentication keys must be configured per interface.
Table 5-6 lists the three OSPF authentication types, along with the interface commands to
both enable authentication and to define the authentication keys. Note that the three authentication
types can be seen in the messages generated by the debug ip ospf adjacency
command.
Key
Topic
Key
Topic
Table 5-6 OSPF Authentication Types
Type Meaning
Enabling Interface
Subcommand
Authentication Key Configuration
Interface Subcommand
0 None ip ospf authentication null —
1 Clear
text
ip ospf authentication ip ospf authentication-key key-value
2 MD5 ip ospf authentication
message-digest
ip ospf message-digest-key key-number
md5 key-value
www.CareerCert.info
160 CCNP ROUTE 642-902 Official Certification Guide
Note: The maximum length of the key is 16 characters.
Although IOS defaults to use type 0 authentication (no authentication), you can override
this default using the area authentication command in OSPF configuration mode. For example,
on a router with 12 interfaces, you plan to use type 2 (MD5) authentication on all
interfaces. Rather than add the ip ospf authentication message-digest command to all 12
interfaces, you could override the default that applies to all interface on that router, in a
given area. Table 5-7 lists the commands to set the default values.
Note that if the area-wide default and the interface subcommand have both been configured,
the interface setting takes precedence. For example, if the interface has been configured
with the ip ospf authentication subcommand (type 1, clear text), and the area
authentication command sets MD5 authentication, that particular interface uses clear text
authentication.
Example 5-7 shows the authentication configuration on Router R3 from Figure 5-4. In this
case, all four routers use MD5 authentication on their common subnet, with key number
1, and key value really-a-secret. R3 also configures simple password authentication on its
Fa0/1 interface, just to demonstrate the various commands. Also for the purposes of
demonstrating the commands, R3 overrides the default authentication, setting the default
area 0 authentication to MD5.
Example 5-7 OSPF Authentication Using Only Interface Subcommands
Key
Topic
! First, overriding the default in area 0 so that it uses MD5 authentication,
! meaning Fa0/0, in area 0, will use MD5.
R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#router ospf 3
R3(config-router)# area 0 authentication message-digest
R3(config-router)#interface fastethernet0/0
R3(config-if)# ip ospf message-digest-key 1 md5 really-a-secret
!
Table 5-7 Effect of the area authentication Command on OSPF Interface Authentication
Settings
area authentication Command Interfaces in That Area Default to Use...
default; no configuration required Type 0
area num authentication Type 1
area num authentication message-digest Type 2
www.CareerCert.info
Chapter 5: OSPF Overview and Neighbor Relationships 161
! Next, two interface subcommands to enable simple password authentication
! on Fa0/1, which is in area 3.
R3(config-if)#interface fastethernet0/1
R3(config-if)#ip ospf authentication
R3(config-if)#ip ospf authentication-key secret
R3(config-if)# ctl-z
R3#
R3#show ip ospf interface fastethernet0/0
! Lines omitted for brevity – the last few lines list authentication information
Message digest authentication enabled
Youngest key id is 1
R3#show ip ospf interface fastethernet0/1
! Lines omitted for brevity – the last few lines list authentication information
Simple password authentication enabled
Note that to verify whether OSPF authentication is enabled, and the authentication type,
use the show ip ospf interface command, and look to the very end of the output, as
shown at the end of Example 5-7. Note that these messages identify the configuration setting
and do nothing to confirm whether authentication passed. To confirm whether it
worked, look for the neighbor in the output of show ip ospf neighbor: A neighbor with
whom authentication fails will not be listed. The reason is that the Hello will be rejected
due to authentication, and the Hello contains several parameters that must be checked before
a router will choose to become an OSPF neighbor with that router. You can also use
the debug ip ospf adj command, whose output explicitly states that a mismatch exists
with the authentication key.
Unlike EIGRP authentication, OSPF authentication does not allow the configuration of a
key chain with time-based authentication keys. However, multiple keys can be configured
on an interface, each with a different key number. To migrate to a new key, you would first
configure a new key value on all routers in a subnet and then delete the configuration of
the old keys.
To avoid having network failures during this cutover, OSPF actually sends and accepts
messages that use all the currently configured authentication keys on the interface. For
example, if the four routers in Figure 5-4 had been configured with key numbers 1 and 2,
every OSPF message would be sent twice–once with each key.
This concludes the discussion of OSPF neighborships on LANs. The final brief section examines
some issues with OSPF neighborship on WANs.
No comments:
Post a Comment