7 - Implement Multiarea OSPF

Procedure https://cll-ng.cisco.
com/content/xtrac/2
Discovery 7: Implement Multiarea OSPF

Task 1: Enable OSPF on R1, R2, and R3
Activity
Step 1: Configure OSPF on WAN and LAN interfaces on the R1 ABR. Use process ID number 1, and network commands for all directly connected networks.
R1# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# router ospf 1
R1(config-router)# network 172.16.145.0 0.0.0.7 area 0
*Jun 19 06:25:45.697: %OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on Ethernet0/1 from LOADING to FULL, Loading Done
To enable the OSPF process on the router, use the router ospf process-id command. Process ID numbers on different sides of the link over which OSPF neighbor relationship will be established do not need to
match. The OSPF process number ID is an internally used identification parameter for an OSPF routing process and has local significance. You can specify multiple OSPF routing processes in a router.
Notice that there are multiple ways to enable OSPF on an interface. To define interfaces on which OSPF process runs and to define the area ID for those interfaces, use the network ip-address wildcard-mask area
area-id command. The combination of ip-address and wildcard-mask allows you to define one or multiple interfaces to be associated with a specific OSPF area using a single command.
Cisco IOS Software sequentially evaluates the ip-address wildcard-mask pair that is specified in the network command for each interface as follows:
It performs a logical OR operation between the wildcard-mask argument and the interface primary IP address.
It performs a logical OR operation between the wildcard-mask argument and the ip-address argument in the network command.
The software compares the two resulting values. If they match, OSPF is enabled on the associated interface and this interface is attached to the specified OSPF area
The area-id identifier is a 32-bit number that may be represented in integer or dotted-decimal format. If represented in dotted-decimal format, the area-id identifier does not represent the IP address, but it is only a
way of writing the same number in integer format. For example, you may specify that an interface belongs to Area 1 using area 1 or area 0.0.0.1 notation in the network command. To establish OSPF full
adjacency, two neighbor routers must be in the same area. Any individual interface can be only attached to a single area. If the address ranges specified for different areas overlap, Cisco IOS Software will adopt
the first area in the network command list and ignore subsequent overlapping portions. You must pay special attention to ensure that address ranges do not overlap to avoid conflicts.
After entering the first network command, you should receive two console messages indicating that R4 and R5 are now OSPF neighbors.
Step 2: Configure OSPF on WAN and LAN interfaces on R2 and R3. On R2, use process ID number 2, and use the OSPF network command for both directly connected networks. On R3, use process ID number
3 and use the network command for the Ethernet WAN link, and the OSPF interface configuration method for Loopback 0.
*Jun 18 08:03:01.831: %OSPF-5-ADJCHG: Process 2, Nbr 1.1.1.1 on Serial0/0 from LOADING to FULL, Loading Done
R3(config-router)# interface Loopback 0
R3(config-if)# ip ospf 3 area 2
Notice the use of the 0.0.0.0 wildcard mask with the network command on R3. This mask indicates that only the interface with the specific IP address listed will be enabled for OSPF.
Another method exists for enabling OSPF on an interface. R3’s loopback 0 interface is included in area 2 by using the ip ospf process-id area area-id command. This method explicitly adds the interface to area 2
without the use of the network command. This capability simplifies the configuration of unnumbered interfaces with different areas and ensures that any new interfaces brought online would not automatically be
included in the routing process. This configuration method is also used for OSPFv3 since that routing protocol doesn’t allow the use of the network statement.
Notice that since OSPF is already enabled on R1, a neighbor adjacency is formed with that router when the network commands are entered on R2 and R3.
Step 3: On R1, R2 and R3, configure the OSPF router ID using the router-id command. Use ID 1.1.1.1 for R1, 2.2.2.2 for R2 and 3.3.3.3 for R3.
R1(config-router)# router-id 1.1.1.1
% OSPF: Reload or use "clear ip ospf process" command, for this to take effect
The OSPF router ID is a fundamental parameter when you want to run the OSPF process. To start the OSPF process, Cisco IOS Software must be able to identify a unique router ID. At least one primary IP
address on an interface in the up/up state must be configured for the router to be able to choose the router ID, otherwise an error message is logged and the OSPF process does not start.
To choose the OSPF router ID at the time of OSPF process initialization, the router uses the following criteria:
Use the router ID specified in the router-id ip-address command. You can configure an arbitrary value in the IP address format, but this value must be unique. If the IP address that is specified with the router-id
command overlaps with the router ID of another already active OSPF process, the router-id command fails.
Use the highest IP address of all active loopback interfaces on the router.
Use the highest IP address among all active nonloopback interfaces.
After the three-step OSPF router ID selection process has ended, and if the router is still not able to select an OSPF router ID, an error message will be logged. An OSPF process that failed to select a router ID,
retries the selection process every time that an IP address becomes available, the interface changes its state to up/up, or, an IP address is configured on the interface.
Step 4: Start by clearing the OSPF routing process on R2 and R3 to allow the manually configured router ID to take effect.
R2# clear ip ospf process
Reset ALL OSPF processes? [no]: yes
R2#
*Jun 19 06:46:05.008: %OSPF-5-ADJCHG: Process 2, Nbr 172.16.145.1 on Serial0/0 from FULL to DOWN, Neighbor Down: Interface down or detached
R3# clear ip ospf 3 process
Reset OSPF process 3? [no]: yes
R3#
*Jun 19 06:47:05.485: %OSPF-5-ADJCHG: Process 3, Nbr 172.16.145.1 on Ethernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached
Once an OSPF router ID is selected, it is not changed, even if the interface that is used to select it changes its operational state or IP address. To change the OSPF router ID, you must reset the OSPF process with
the clear ip ospf process command or reload the router.
In production networks, the OSPF router ID cannot be changed easily. Change of the OSPF router ID requires reset of all OSPF adjacencies, resulting in a temporary routing outage. The router also must originate
new copies of all its own LSAs with the new router ID.
You can either clear the specific OSPF process by specifying the process ID, or you can reset all OSPF processes using the clear ip ospf process command.
When the clear ip ospf process command is entered on R2 and R3, notice that the router ID being advertised by R1 is 172.16.145.1. R1 has no loopback interfaces and it didn’t have a manually configured router
1 din 8 26.05.2020, 11:18

Procedure https://cll-ng.cisco.com/content/xtrac/2
ID when the OSPF process was enabled. R1 chose the highest IP address among all active nonloopback interfaces as its initial router ID.
Step 5: Clear the OSPF routing process on R1 to allow the manually configured router ID to take effect.
R1#
*Jun 19 06:50:49.146: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial2/0 from FULL to DOWN, Neighbor Down: Interface down or detached
R1#
The OSPF neighbor adjacencies messages show that all routers are now using manually configured router IDs.
Note
You might notice a console message on R2 or R3 indicating that the 172.16.145.1 neighbor is down because the Dead timer is expired. This occurrence is normal OSPF behavior and allows the neighbor table to
flush incorrect entries since R1 is now using the 1.1.1.1 router ID instead.
Task 2: Verify OSPF Functionality

Activity
Step 1: Verify the newly configured OSPF router ID on R2 and R3 using the show ip protocol command.
R2# show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "ospf 2"

Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID 2.2.2.2
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Maximum path: 4
Routing for Networks:
172.16.12.0 0.0.0.3 area 1
192.168.2.0 0.0.0.255 area 1
Routing Information Sources:
Gateway Distance Last Update
1.1.1.1 110 00:02:55
Distance: (default is 110)
R3# show ip protocols | include ID
Router ID 3.3.3.3
You can verify the newly configured OSPF router ID using the show ip protocols command. The large output of this command can, optionally, be filtered using the pipe function.
Step 2: Investigate the OSPF adjacency on R2 and R3 using the show ip ospf neighbor command.
R2# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface

1.1.1.1 1 FULL/ - 00:01:57 172.16.12.1 Serial0/0

1.1.1.1 1 FULL/DR 00:00:39 172.16.13.1 Ethernet0/0
The command show ip ospf neighbor displays OSPF neighbor information on a per-interface basis. The significant fields of the output are as follows:
Neighbor ID: Represents the neighbor router ID

Priority: Priority on the neighbor interface that is used for the DR, and BDR election
State: The FULL state represents the final stage of the OSPF neighbor establishment process and denotes that the local router has established full neighbor adjacency with the remote OSPF neighbor. The
hyphen (“-“) indicates that a designated router wasn’t needed for this type of network. The serial interface is treated by OSPF as a point-to-point link since only 2 routers will ever be on this segment. DR means
that the DR, and BDR election process has been completed and the remote router with the router ID 1.1.1.1 has been elected as the DR.
Dead Time: Represents the value of the dead timer. When this timer expires, the router terminates the neighbor relationship. Each time that the router receives an OSPF hello packet from a specific neighbor, it
resets the dead timer back to its full value.
Address: The primary IP address of the neighbor router
Interface: The local interface over which the OSPF neighbor relationship is established
Step 3: Verify OSPF enabled interfaces on R2 and R3 using the show ip ospf interface command.
R2# show ip ospf interface
Loopback0 is up, line protocol is up
Internet Address 192.168.2.1/24, Area 1, Attached via Interface Enable
Process ID 2, Router ID 2.2.2.2, Network Type LOOPBACK, Cost: 1
<…output omitted…>
Serial0/0 is up, line protocol is up
Internet Address 172.16.12.2/30, Area 1, Attached via Network Statement
Process ID 2, Router ID 2.2.2.2, Network Type POINT_TO_POINT, Cost: 64
R3# show ip ospf interface
Loopback0 is up, line protocol is up
Process ID 3, Router ID 3.3.3.3, Network Type LOOPBACK, Cost: 1
Ethernet0/0 is up, line protocol is up
Process ID 3, Router ID 3.3.3.3, Network Type BROADCAST, Cost: 10
The output of the show ip ospf interface command shows you all interfaces that are enabled in the OSPF process. For each enabled interface, you can see detailed information such as OSPF area ID, OSPF
process ID, and how the interface was included into the OSPF process. In the output, you can see that both interfaces on R3 were included via the network statement, which is configured with the network
command. R2 shows that Loopback 0 was included via the explicit interface configuration method, and Serial 0/0 was included via the network statement.
Step 4: Verify OSPF routes in the routing table on R5 using the show ip route ospf command.
R5# show ip route ospf
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
2 din 8 26.05.2020, 11:18

Gateway of last resort is not set
172.16.0.0/16 is variably subnetted, 4 subnets, 3 masks

O IA 172.16.12.0/30 [110/74] via 172.16.145.1, 00:39:00, Ethernet0/0
O IA 172.16.13.0/30 [110/20] via 172.16.145.1, 00:19:29, Ethernet0/0
192.168.2.0/32 is subnetted, 1 subnets
O IA 192.168.2.1 [110/75] via 172.16.145.1, 00:07:27, Ethernet0/0
192.168.3.0/32 is subnetted, 1 subnets
O IA 192.168.3.1 [110/21] via 172.16.145.1, 00:08:30, Ethernet0/0
O 192.168.4.0/24 [110/11] via 172.16.145.4, 00:39:10, Ethernet0/0
Among routes that are originated within an OSPF autonomous system, OSPF clearly distinguishes two types of routes: intra-area routes and interarea routes. Intra-area routes are routes that are originated and
learned in the same local area. The character “O” is the code for the intra-area routes in the routing table. The second type is interarea routes, which originate in other areas and are inserted into the local area to
which your router belongs. The characters “O IA” are the code for the interarea routes in the routing table. Interarea routes are inserted into other areas by the ABR.
The prefix 192.168.4.0/24 is an example of an intra-area route from the perspective of R5. It originated from router R4, which is part of Area 0, the same area as R5.
The prefixes from R2 and R3, which is part of Area 1 and area 2, are shown in the routing table on R5 as interarea routes. The prefixes were inserted into Area 0 as interarea routes by R1, which plays the role of
ABR.
The prefixes 192.168.2.0/24 and 192.168.3.0/24 configured on the Loopback interfaces of R2 and R3 are displayed in the R5 routing table as host routes 192.168.2.1/32 and 192.168.3.1/32. By default, OSPF will
advertise any subnet that is configured on the loopback interface as /32 host route. To change this default behavior, you can change the OSPF network type on the loopback interface from default loopback to
point-to-point, using the ip ospf network point-to-point interface command.
Step 5: Observe OSPF routes on R5 by entering the show ip ospf route command.
R5# show ip ospf route
OSPF Router with ID (5.5.5.5) (Process ID 1)
Base Topology (MTID 0)
Area BACKBONE(0)
Intra-area Route List

* 172.16.145.0/29, Intra, cost 10, area 0, Connected
via 172.16.145.5, Ethernet0/0
*> 192.168.4.0/24, Intra, cost 11, area 0
via 172.16.145.4, Ethernet0/0
Intra-area Router Path List

i 1.1.1.1 [10] via 172.16.145.1, Ethernet0/0, ABR, Area 0, SPF 2
Interarea Route List

*> 192.168.2.1/32, Inter, cost 75, area 0
via 172.16.145.1, Ethernet0/0
*> 192.168.3.1/32, Inter, cost 21, area 0
via 172.16.145.1, Ethernet0/0
*> 172.16.12.0/30, Inter, cost 74, area 0
via 172.16.145.1, Ethernet0/0
*> 172.16.13.0/30, Inter, cost 20, area 0
via 172.16.145.1, Ethernet0/0
The command show ip ospf route gives you clearly separated lists of intra-area and interarea routes. In addition, the output of the command gives you essential information about Area Border Routers, including
the router ID, IP address in the current area, the interface that advertises routes into the area, and the area ID.
For the interarea routes, the metric for the route (cost), area into which route is distributed, and the interface over which the route is inserted are displayed.
OSPF Neighbor States
OSPF neighbors go through multiple neighbor states before forming a full OSPF adjacency.
OSPF routers progress through seven states:
Down: No active neighbor detected

INIT: Hello packet is received from neighbor
2-WAY: Own router ID in received hello
Exstart: Master and slave roles determined
Exchange: Database description packets sent
Loading: Exchange of LSRs and LSUs
Full: Neighbors fully adjacent
The following is a summary of the states that an interface passes through before establishing as adjacency with another router:
DOWN: No information has been received on the segment.

INIT: The interface has detected a hello packet coming from a neighbor, but bidirectional communication has not yet been established.
2-WAY: There is bidirectional communication with a neighbor. The router has seen itself in the hello packets coming from a neighbor. At the end of this stage, the DR, and BDR election will be performed if
necessary. When routers are in the 2-WAY state, they must decide whether to proceed in building an adjacency. The decision is based on whether one of the routers is a DR or BDR or if the link is a point-to-point
or a virtual link.
EXSTART: Routers are trying to establish the initial sequence number that is going to be used in the information exchange packets. The sequence number ensures that routers always get the most recent
information. One router will become the master and the other will become the slave. The master router will poll the slave for information.
EXCHANGE: Routers will describe their entire LSDB by sending database description packets (DBD). In this state, packets may be flooded to other interfaces on the router.
LOADING: In this state, routers are finalizing the information exchange. Routers have built a link-state request list and a link-state retransmission list. Any information that looks incomplete or outdated will be put
on the request list. Any update that is sent will be put on the retransmission list until it gets acknowledged.
FULL: In this state, adjacency is complete. The neighboring routers are fully adjacent. Adjacent routers will have similar LSDBs.
Step 6: Observe the OSPF neighbor adjacency formation and OSPF packet types on R3 using the debug ip ospf adj and clear ip ospf process commands. Disable debug when the OSPF session is re-established.
R3# debug ip ospf adj
OSPF adjacency debugging is on

*Jan 17 13:02:37.394: OSPF-3 ADJ Lo0: Interface going Down
*Jan 17 13:02:37.394: OSPF-3 ADJ Lo0: 3.3.3.3 address 192.168.3.1 is dead, state DOWN
*Jan 17 13:02:37.394: OSPF-3 ADJ Et0/0: Interface going Down
*Jan 17 13:02:37.394: OSPF-3 ADJ Et0/0: 1.1.1.1 address 172.16.13.1 is dead, state DOWN
*Jan 17 13:02:37.394: %OSPF-5-ADJCHG: Process 3, Nbr 1.1.1.1 on Ethernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached
<... output omitted ...>
*Jan 17 13:02:37.394: OSPF-3 ADJ Lo0: Interface going Up
*Jan 17 13:02:37.394: OSPF-3 ADJ Et0/0: Interface going Up
*Jan 17 13:02:37.395: OSPF-3 ADJ Et0/0: 2 Way Communication to 1.1.1.1, state 2WAY
*Jan 17 13:02:37.396: OSPF-3 ADJ Et0/0: Backup seen event before WAIT timer
*Jan 17 13:02:37.396: OSPF-3 ADJ Et0/0: DR/BDR election
*Jan 17 13:02:37.396: OSPF-3 ADJ Et0/0: Elect BDR 3.3.3.3
3 din 8 26.05.2020, 11:18

*Jan 17 13:02:37.396: OSPF-3 ADJ Et0/0: Elect DR 1.1.1.1

*Jan 17 13:02:37.396: OSPF-3 ADJ Et0/0: DR: 1.1.1.1 (Id) BDR: 3.3.3.3 (Id)
*Jan 17 13:02:37.396: OSPF-3 ADJ Et0/0: Nbr 1.1.1.1: Prepare dbase exchange
*Jan 17 13:02:37.396: OSPF-3 ADJ Et0/0: Send DBD to 1.1.1.1 seq 0x95D opt 0x52 flag 0x7 len 32
*Jan 17 13:02:37.397: OSPF-3 ADJ Et0/0: Rcv DBD from 1.1.1.1 seq 0x691 opt 0x52 flag 0x7 len 32 mtu 1500 state EXSTART
*Jan 17 13:02:37.397: OSPF-3 ADJ Et0/0: First DBD and we are not SLAVE
*Jan 17 13:02:37.397: OSPF-3 ADJ Et0/0: Rcv DBD from 1.1.1.1 seq 0x95D opt 0x52 flag 0x2 len 152 mtu 1500 state EXSTART
*Jan 17 13:02:37.397: OSPF-3 ADJ Et0/0: NBR Negotiation Done. We are the MASTER
*Jan 17 13:02:37.397: OSPF-3 ADJ Et0/0: Nbr 1.1.1.1: Summary list built, size 0
*Jan 17 13:02:37.397: OSPF-3 ADJ Et0/0: Send DBD to 1.1.1.1 seq 0x95E opt 0x52 flag 0x1 len 32
*Jan 17 13:02:37.398: OSPF-3 ADJ Et0/0: Rcv DBD from 1.1.1.1 seq 0x95E opt 0x52 flag 0x0 len 32 mtu 1500 state EXCHANGE
*Jan 17 13:02:37.398: OSPF-3 ADJ Et0/0: Exchange Done with 1.1.1.1
*Jan 17 13:02:37.398: OSPF-3 ADJ Et0/0: Send LS REQ to 1.1.1.1 length 96 LSA count 6
*Jan 17 13:02:37.399: OSPF-3 ADJ Et0/0: Rcv LS UPD from 1.1.1.1 length 208 LSA count 6
*Jan 17 13:02:37.399: OSPF-3 ADJ Et0/0: Synchronized with 1.1.1.1, state FULL
*Jan 17 13:02:37.399: %OSPF-5-ADJCHG: Process 3, Nbr 1.1.1.1 on Ethernet0/0 from LOADING to FULL, Loading Done
R3# undebug all
An OSPF adjacency is established in several steps. First, routers that intend to establish full OSPF neighbor adjacency exchange OSPF hello packets. Both OSPF neighbors are in the DOWN state (the initial state
of a neighbor conversation that indicates that no hello’s have been heard from the neighbor). When a router receives a hello from the neighbor but has not yet seen its own router ID in the neighbor hello packet, it
will transit to the INIT state. In this state, the router will record all neighbor router IDs and start including them in hellos sent to the neighbors. When the router sees its own router ID in the hello packet that is
received from the neighbor, it will transit to the 2-WAY state. This state means that bidirectional communication with the neighbor has been established.
On broadcast links, OSPF neighbors first determine DR and BDR roles, which optimize the exchange of information in broadcast segments.
In the next step, the routers start to exchange the content of OSPF databases. The first phase of this process is to determine the master/slave relationship and choose the initial sequence number for adjacency
formation. To accomplish that phase, the routers exchange DBD packets. When the router receives the initial DBD packet, it transitions the state of the neighbor from which this packet is received to the
EXSTART state, populates its Database Summary list with the LSAs that describe the content of the neighbor database, and sends its own empty DBD packet. In the DBD exchange process, the router with the
higher router ID will become master and it will be the only router that can increment sequence numbers.
With master/slave selection complete, the database exchange can start. R3 will transit R1’s neighbor state to EXCHANGE. In this state, R3 describes its database to R1 by sending DBD packets, which contain the
headers of all LSAs in the Database Summary list. The Database Summary list gives the description of all LSAs in the router’s database, but not the full content of the OSPF database. To describe the content of
the database, one or multiple DBD packets may be exchanged. The router compares the content of its own Database Summary list with the list received from the neighbor, and if there are differences, it adds the
missing LSAs to the Link State Request list. At this point, the routers enter the LOADING state. R3 sends an LSR packet to the neighbor, requesting full content of the missing LSAs from the LS Request list. R1
replies with the LSU packets, which contain the full version of the missing LSAs.
Finally, when neighbors have the full version of the LS database, both neighbors will transit to the FULL state, which means that databases on the routers are synchronized and neighbors are fully adjacent.
Task 3: Verify DR and BDR Election

Activity
Optimizing OSPF Adjacency Behavior
DR/BDR election occurs on multiaccess broadcast and nonbroadcast networks
The DR/BDR election improves network functioning in the following ways:
Reducing routing update traffic
Managing link state synchronization
Multiaccess networks, either broadcast (such as Ethernet) or nonbroadcast (such as Frame Relay), represent interesting issues for OSPF. All routers sharing the common segment will be part of the same IP subnet.
When forming adjacency on a multiaccess network, every router will try to establish full OSPF adjacency with all other routers on the segment. This behavior may not represent an issue for the smaller multiaccess
broadcast networks, but it may represent an issue for the NBMA, where, usually, you do not have full-mesh PVC topology. This issue in NBMA networks manifests itself in the inability for neighbors to synchronize
their OSPF databases directly among themselves. A logical solution, in this case, is to have a central point of OSPF adjacency responsible for the database synchronization and advertisement of the segment to the
other routers.
As the number of routers on the segment grows, the number of OSPF adjacencies increases exponentially. Every router must synchronize its OSPF database with every other router, and in the case of many routers on
segment, this behavior leads to inefficiency. Another issue arises when every router on the segment advertises all its adjacencies to other routers in the network. If you have full-mesh OSPF adjacencies, the other
OSPF routers will receive a large amount of redundant link-state information. The solution for this problem is again to establish a central point with which every other router forms an adjacency, and which advertises
the segment to the rest of the network.
The routers on the multiaccess segment elect a DR and a BDR that centralize communication for all routers that are connected to the segment. The DR and BDR improve network functionality in the following ways:
Reducing routing update traffic: The DR and BDR act as a central point of contact for link-state information exchange on a multiaccess network. Therefore, each router must establish a full adjacency with the
DR, and the BDR. Each router, rather than exchanging link-state information with every other router on the segment, sends the link-state information to the DR and BDR only by using the dedicated multicast
address 224.0.0.6. The DR represents the multiaccess network in the sense that it sends link-state information from each router to all other routers in the network. This flooding process significantly reduces the
router-related traffic on the segment.
Managing link-state synchronization: The DR and BDR ensure that the other routers on the network have the same link-state information about the common segment. In this way, the DR, and BDR reduce the
number of routing errors.
When the DR is operating, the BDR does not perform any DR functions. Instead, the BDR receives all the information, but the DR performs the LSA forwarding and LSDB synchronization tasks. The BDR performs
the DR tasks only if the DR fails. When the DR fails, the BDR automatically becomes the new DR, and a new BDR election occurs.
Step 1: Examine the DR/BDR status on R1, R4, and R5 using the show ip ospf neighbor command.
Routers R1, R4, and R5 are all connected to the same shared network segment, where OSPF will automatically try to optimize adjacencies.
4 din 8 26.05.2020, 11:18

4.4.4.4 1 FULL/BDR 00:00:37 172.16.145.4 Ethernet0/1

5.5.5.5 1 FULL/DR 00:00:39 172.16.145.5 Ethernet0/1
2.2.2.2 0 FULL/ - 00:01:53 172.16.12.2 Serial2/0
3.3.3.3 1 FULL/BR 00:00:35 172.16.13.2 Ethernet0/0

1.1.1.1 1 FULL/DROTHER 00:00:39 172.16.145.1 Ethernet0/0
5.5.5.5 1 FULL/DR 00:00:39 172.16.145.5 Ethernet0/0

When R1, R4, and R5 start establishing OSPF neighbor adjacency, they will first send OSPF hello packets to discover which OSPF neighbors are active on the common Ethernet segment. After the bidirectional
communication between routers is established and they are all in OSPF neighbor 2-WAY state, the DR/BDR election process begins. The OSPF hello packet contains three specific fields that are used for the
DR/BDR election: Designated Router, Backup Designated Router, and Router Priority.
The Designated Router and Backup Designate Router fields are populated with a list of routers claiming to be DR, and BDR. From all routers that are listed, the router with the highest priority becomes the DR,
and the router with the next highest priority becomes the BDR. If the priority values are equal, the router with the highest OSPF router ID becomes the DR, and the router with the next highest OSPF router ID
becomes BDR.
The DR/BDR election process takes place on broadcast and nonbroadcast multiaccess networks. The main difference between the two is the type of IP address that is used in the hello packet. On the multiaccess
broadcast networks, routers use multicast destination IP address 224.0.0.6 to communicate with the DR (called AllDRRouters) and the DR uses multicast destination IP address 224.0.0.5 to communicate with all
other non-DR routers (called AllSPFRouters). On NBMA networks, the DR and adjacent routers communicate using unicast.
The procedure of DR/BDR election occurs not only when the network first becomes active, but also when the DR becomes unavailable. In this case, the BDR will immediately become the DR, and the election of
the new BDR starts.
In the topology, R5 has been elected as the DR, and R4 as the BDR, due to the highest router-id values on the segment. R1 became DROTHER. On the multiaccess segment, it is normal behavior that the router in
DROTHER status is fully adjacent with DR/BDR, and in a 2-WAY state with all other DROTHER routers present on the segment.
Step 2: On R5, shut down the interface towards R1 and R4. Re-examine DR/BDR status on R1 and R4.
After you shut down the interface, wait until the neighbor adjacencies expire before re-examining the DR/BDR state.
R5(config)# interface ethernet 0/0
R5(config-if)# shutdown
*Dec 8 16:20:25.080: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on Ethernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached

4.4.4.4 1 FULL/DR 00:00:32 172.16.145.4 Ethernet0/1
2.2.2.2 0 FULL/ - 00:01:36 172.16.12.2 Serial2/0
3.3.3.3 1 FULL/DR 00:00:39 172.16.13.2 Ethernet0/0

When you shut down Ethernet 0/0 on R5, the DR router on the segment becomes unavailable but because shutting down the Ethernet 0/0 interface on R5 is seen as an indirect loss of adjacency, R1 will only
declare R5 down after the Dead timer of 40 seconds has expired. This issue also applies to R4. After the Dead timer expires, a new DR/BDR election takes place. The output of the show ip ospf neighbor
command shows that R4 has become the DR, and R1 the BDR.
Note that because shutting down the Ethernet 0/0 interface on R5 is seen as an indirect loss of adjacency, R1 will only declare R5 down after the Dead timer of 40 seconds has expired. This issue will also apply to
R4.
Step 3: On R5, enable the interface towards R1 and R4. Examine the DR/BDR status on R1, R4, and R5.
R5(config-if)# no shutdown
*Dec 10 08:49:26.491: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on Ethernet0/0 from LOADING to FULL, Loading Done

4.4.4.4 1 FULL/DR 00:00:36 172.16.145.4 Ethernet0/1
2.2.2.2 0 FULL/ - 00:01:52 172.16.12.2 Serial2/0
3.3.3.3 1 FULL/DR 00:00:33 172.16.13.2 Ethernet0/0


4.4.4.4 1 FULL/DR 00:00:37 172.16.145.4 Ethernet0/0
When you re-enable R5 in the Ethernet 0/0 interface, a new DR/BDR election process will not take place, although R5 has the highest OSPF router ID on the segment. Once the DR and BDR are elected, they are
not pre-empted. This rule makes a multiaccess segment more stable by preventing the election process from occurring when a new router becomes active. It means that the first two DR-eligible routers on the link
will be elected as DR and BDR. A new election will occur only when one of them fails.
Using OSPF Priority in the DR/BDR Election
OSPF hello packet that is used in DR/BDR election contains Router Priority field.
The router with the highest OSPF priority will be elected as DR.
The router with the second-highest OSPF priority will be elected as BDR.
The router with the priority set to 0 does not participate in the DR/BDR election and is not eligible to become the DR/BDR.
5 din 8 26.05.2020, 11:18

One of the fields in the OSPF hello packet that is used in the DR/BDR election process is the Router Priority field. Every broadcast and nonbroadcast multiaccess OSPF-enabled interface has an assigned priority
value, which is a number between 0 and 255. By default, in Cisco IOS Software, the OSPF interface priority value is 1. You can manually change it using either the ip ospf priority interface level command. To elect
a DR, and BDR, the routers view the OSPF priority value of other routers during the hello packet exchange process and then use the following conditions to determine which router to select:
The router with the highest priority value is elected as the DR.
The router with the second-highest priority value is the BDR.
If there is a tie, where two routers have the same priority value, the router ID is used as the tie-breaker. The router with the highest router ID becomes the DR. The router with the second-highest router ID becomes
the BDR.
A router with a priority that is set to 0 cannot become the DR or BDR. A router that is not the DR or BDR is called a DROTHER.
Step 4: On R1, configure OSPF priority using ip ospf priority interface level command. Clear the OSPF process on R4 to re-initiate the DR/BDR election process.
Setting the OSPF interface priority globally to a value higher than 1 will influence the DB/BDR election in favor of R1.
R1(config-if)# ip ospf priority 100
In this step, you set the OSPF interface priority value to 100. In this way, you influence the DR/BDR election and the R1 router will become the DR after you clear the OSPF process on the current DR, R4.
Step 5: On R1, verify that it has been elected as a new DR by entering the show ip ospf interface Ethernet 0/1 command.
R1# show ip ospf interface ethernet 0/1
Topology-MTID Cost Disabled Shutdown Topology Name
0 10 no no Base
Transmit Delay is 1 sec, State DR, Priority 100
Designated Router (ID) 1.1.1.1, Interface address 172.16.145.1
Backup Designated router (ID) 5.5.5.5, Interface address 172.16.145.5
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:06
Supports Link-local Signaling (LLS)
Cisco NSF helper support enabled
IETF NSF helper support enabled
Index 1/3, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 5
Last flood scan time is 0 msec, maximum is 1 msec
Neighbor Count is 2, Adjacent neighbor count is 2
Adjacent with neighbor 4.4.4.4
Adjacent with neighbor 5.5.5.5 (Backup Designated Router)
Suppress hello for 0 neighbor(s)
The output of the show ip ospf interface command on R1 shows that R1 is elected as the DR, and R5 is elected as the BDR. R1 is fully adjacent with two neighbors, R4 and R5.
Step 6: On R4 and R5, set the OSPF priority on the Ethernet 0/0 interfaces to 0 using the ip ospf priority level command.
Setting the OSPF priority to a value of 0 on the Ethernet 0/0 interfaces of R4 and R5 causes these two routers to not participate in DR/BDR election. They will not be eligible to become DR/BDR. Such routers
will have the DROTHER function.
Step 7: Verify DR/BDR status on R1, R4, and R5.

2.2.2.2 0 FULL/ - 00:01:33 172.16.12.2 Serial2/0
3.3.3.3 1 FULL/DR 00:00:30 172.16.13.2 Ethernet0/0

1.1.1.1 100 FULL/DR 00:00:37 172.16.145.1 Ethernet0/0
5.5.5.5 0 2WAY/DROTHER 00:00:37 172.16.145.5 Ethernet0/0

1.1.1.1 100 FULL/DR 00:00:32 172.16.145.1 Ethernet0/0
4.4.4.4 0 2WAY/DROTHER 00:00:37 172.16.145.4 Ethernet0/0
Output of the show ip ospf neighbor command on R1 shows that R1 is fully adjacent with R4 and R5 and that R4 and R5 have DROTHER functions. R4 is fully adjacent with the DR router R1 while it maintains
2-WAY state with its peer DROTHER router R5. Similarly, R5 is fully adjacent with DR R1 and maintains 2-WAY state with DROTHER router R4. 2-WAY state between non-DR/BDR routers on the segment is
normal behavior, they do not synchronize LSDBs directly but over DR/BDR. By maintaining 2-WAY state, DROTHER routers keep other DROTHER peers informed about their presence on the network.
Task 4: Examine MTU-Related OSPF Issues

Activity
Importance of MTU
IP MTU determines the maximum size of the packet that can be forwarded without fragmentation.
Mismatched MTUs can lead to an inconsistent OSPF database.
OSPF requires the same MTUs to be configured on both sides of the link.
OSPF neighbors with mismatched MTUs are stuck in the EXSTART adjacency state.
The IP MTU parameter determines the maximum size of the IP packet that can be forwarded out the interface without the fragmentation. If a packet with an IP MTU larger than the maximum arrives at the router
interface, it will either be discarded if the DF bit in the packet header is set, or it will be fragmented. OSPF packets completely rely on IP for the possible fragmentation. Although RFC 2328 does not recommend
OSPF packet fragmentation, there may arise a situation in which the size of the OSPF packet has greater value than the interface IP MTU. If MTUs are mismatched between two neighbors, this condition can
introduce issues with the exchange of link-state packets, resulting in continuous retransmissions.
To prevent such issues, OSPF requires that the same IP MTU is configured on both sides of the link. If neighbors have mismatched IP MTU configured, they will not be able to form full OSPF adjacency. They will
be stuck in the EXSTART adjacency state.
Step 1: Change the IP MTU size on R3 Ethernet0/0 interface to 1400.
R3(config-if)# ip mtu 1400
6 din 8 26.05.2020, 11:18

You have changed the IP MTU size on the R3 Ethernet 0/0 interface to create a mismatch between IP MTU sizes on the link between R3 and R1. This mismatch will generate a situation in which R3 and R1 are
not able to synchronize their OSPF databases and a new full adjacency between them will never be established.
Step 2: Enable debugging of the OSPF adjacency on R3, using the debug ip ospf adj command. Clear the OSPF process to reset the adjacency and disable debug when the OSPF session is re-established.
R3# debug ip ospf adj
*Jan 19 17:37:05.969: OSPF-3 ADJ Et0/0: Interface going Up
*Jan 19 17:37:05.969: OSPF-3 ADJ Et0/0: 2 Way Communication to 1.1.1.1, state 2WAY
*Jan 19 17:37:05.969: OSPF-3 ADJ Et0/0: Backup seen event before WAIT timer
*Jan 19 17:37:05.969: OSPF-3 ADJ Et0/0: DR/BDR election
*Jan 19 17:37:05.969: OSPF-3 ADJ Et0/0: DR: 1.1.1.1 (Id) BDR: 3.3.3.3 (Id)
*Jan 19 17:37:05.970: OSPF-3 ADJ Et0/0: Nbr 1.1.1.1: Prepare dbase exchange
*Jan 19 17:37:05.970: OSPF-3 ADJ Et0/0: Send DBD to 1.1.1.1 seq 0x21D6 opt 0x52 flag 0x7 len 32
*Jan 19 17:37:05.970: OSPF-3 ADJ Et0/0: Rcv DBD from 1.1.1.1 seq 0x968 opt 0x52 flag 0x7 len 32 mtu 1500 state EXSTART
*Jan 19 17:37:05.970: OSPF-3 ADJ Et0/0: Nbr 1.1.1.1 has larger interface MTU
*Jan 19 17:37:05.970: OSPF-3 ADJ Et0/0: Rcv DBD from 1.1.1.1 seq 0x21D6 opt 0x52 flag 0x2 len 112 mtu 1500 state EXSTART
*Jan 19 17:37:05.970: OSPF-3 ADJ Et0/0: Nbr 1.1.1.1 has larger interface MTU
R3# no debug ip ospf adj
The DBD packet carries information about the largest non-fragmented packet that can be sent from the neighbor. In this situation, IP MTU values on different sides of the link are not equal. R3 will receive a DBD
packet with an IP MTU size 1500, which is greater than its own MTU size of 1400. This condition will result in the inability of both R3 and R1 to establish full neighbor adjacency, and the output of the debug
command will display "Nbr has larger interface MTU” message. Mismatched neighbors will stay in EXSTART state. To form full OSPF adjacency, IP MTU needs to match on both sides of the link.
Step 3: Verify the OSPF neighbor state on R3 and R1.

1.1.1.1 1 EXSTART/BDR 00:00:38 172.16.13.1 Ethernet0/0

2.2.2.2 0 FULL/ - 00:01:55 172.16.12.2 Serial2/0
3.3.3.3 1 EXCHANGE/DR 00:00:36 172.16.13.2 Ethernet0/0

2.2.2.2 0 FULL/ - 00:01:31 172.16.12.2 Serial2/0
3.3.3.3 1 INIT/DROTHER 00:00:33 172.16.13.2 Ethernet0/0
Mismatching interface IP MTU sizes on opposite sides of the OSPF link result in the inability to form full adjacency. R3, which detected that R1 has a higher MTU, keeps neighbor adjacency in EXSTART state.
R1 continues to retransmit an initial BDB packet to R3, but R3 is not able to acknowledge them due to the unequal IP MTU. On R1, you can observe how the OSPF adjacency state with R3 is unstable. The
adjacency gets to the EXCHANGE state, but it is then terminated, starting again from the INIT state up to the EXCHANGE state in a cycle.
Note
The recommended way to fix such issues is to make sure that the IP MTU matches between OSPF neighbors.
Step 4: Change the IP MTU size on R3 Ethernet0/0 interface to 1500 to match the value on R1.
R3(config-if)# ip mtu 1500
When the MTU mismatch is corrected, the OSPF neighbor adjacency is re-established.
Task 5: Modify OSPF Timers

Activity
Manipulating OSPF Timers
OSPF uses hello and dead timers to monitor neighbor reachability.
To form an OSPF neighbor adjacency, hello and dead interval timers must match.
OSPF hello timer default values:
Broadcast and point-to-point links: 10 seconds
All other OSPF network types: 30 seconds
Default value for OSPF dead timer is four times the hello interval.
The debug ip ospf hello command can be used to see a mismatch in hello timers.
Like EIGRP, OSPF uses two timers to check neighbor reachability. These two timers are named hello and dead intervals. The values of the hello and dead intervals are carried in the OSPF hello packet, which serves
as a keepalive message with the purpose of acknowledging the router presence on the segment. The hello interval specifies the frequency of sending OSPF hello packets in seconds. The SPF dead timer specifies how
long a router waits to receive a hello packet before it declares the neighbor router down.
OSPF requires that both the hello and dead timers are identical for all routers on the segment to become OSPF neighbors. The default value of the OSPF hello timer on multiaccess broadcast and point-to-point links
is 10 seconds and on all other network types, including nonbroadcast (NBMA), is 30 seconds. Once you set up the hello interval, the default value of the dead interval will automatically be four times the hello
interval. For broadcast and point-to-point links, it is 40 seconds and for all other OSPF network types, it is 120 seconds.
To detect faster topological changes, you can lower the value of the OSPF hello interval, with the downside of having more routing traffic on the link.
To investigate the mismatch of the hello timers, use the debug ip ospf hello command.
Step 1: On R1, investigate hello and dead timer values on Ethernet 0/1 and Serial 2/0 interfaces, using the show ip ospf interface command.
R1# show ip ospf interface Ethernet 0/1
0 10 no no Base
Transmit Delay is 1 sec, State DROTHER, Priority 1
Designated Router (ID) 5.5.5.5, Interface address 172.16.145.5
Backup Designated router (ID) 4.4.4.4, Interface address 172.16.145.4
R1# show ip ospf interface Serial 2/0

Serial2/0 is up, line protocol is up
7 din 8 26.05.2020, 11:18

Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost: 64

0 64 no no Base
Transmit Delay is 1 sec, State POINT_TO_POINT
The default value of the OSPF hello interval on broadcast multiaccess (Ethernet) and point-to-point links are 10 seconds, while the default value of the dead interval is four times hello, or 40 seconds. The default
values of the OSPF hello and dead timers on all other OSPF network types, including nonbroadcast (NBMA) such as Frame Relay, is 30 seconds and 120 seconds, respectively.
On low-speed links, you may want to alter the default OSPF timer values to achieve faster convergence. The negative aspect of lowering the OSPF hello interval is the overhead of more frequent routing updates,
causing higher router utilization, and more traffic on the link.
Step 2: On R1, lower the default OSPF hello and dead intervals on the Serial 2/0 interface.
The OSPF timer can be changed using the ip ospf hello-interval and ip ospf dead-interval interface commands.
R1(config-if)# interface serial 2/0
R1(config-if)# ip ospf hello-interval 5
R1(config-if)# ip ospf dead-interval 30
*Jun 18 08:40:32.231: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial2/0 from FULL to DOWN, Neighbor Down: Dead timer expired
Once you change the default OSPF hello and dead interval values on the serial link, both routers will detect a hello timer mismatch. As a result, the dead timer will not be refreshed, so it will expire, declaring the
OSPF neighbor relationship as down.
Note
When changing only the OSPF hello interval, OSPF automatically changes the dead interval to four times the hello interval, unless otherwise specified.
Step 3: On R2, lower the default OSPF hello and dead timers on the serial 0/0 interface so that they match the respective values that are configured on R1.
R2(config)# interface serial 0/0
R2(config-if)# ip ospf hello-interval 5
R2(config-if)# ip ospf dead-interval 30
When you change the OSPF hello and dead timers on R2 so that they match the timers on R1, both routers on the link will be able to establish adjacency on the serial link. After that, the routers will exchange and
synchronize link-state databases and form FULL neighbor adjacency.
Step 4: On R2, verify the OSPF neighbor state using the show ip ospf neighbor detail command.
R2# show ip ospf neighbor detail
Neighbor 1.1.1.1, interface address 172.16.12.1
In the area 1 via interface Serial0/0
Neighbor priority is 0, State is FULL, 6 state changes
DR is 0.0.0.0 BDR is 0.0.0.0
Options is 0x12 in Hello (E-bit, L-bit)
Options is 0x52 in DBD (E-bit, L-bit, O-bit)
LLS Options is 0x1 (LR)
Dead timer due in 00:00:29
Neighbor is up for 00:01:56
Index 1/1, retransmission queue length 0, number of retransmission 0
First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)
Last retransmission scan length is 0, maximum is 0
Last retransmission scan time is 0 msec, maximum is 0 msec
The output of the show ip ospf neighbor detail command confirms that full OSPF adjacency with R1 is established. The output also shows additional information regarding the neighbor router ID and how long
the neighbor session has been established. Notice that since OSPF is treating this interface as network type POINT-TO-POINT, the neighbor priority is automatically set to 0, and the DR and BDR addresses are
set to 0.0.0.0.
© 2020 Cisco Systems, Inc.
8 din 8 26.05.2020, 11:18

7 - Implement Multiarea OSPF

Uploaded by

Copyright:

Available Formats

7 - Implement Multiarea OSPF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

7 - Implement Multiarea OSPF

Uploaded by

Copyright:

Available Formats

Procedure https://cll-ng.cisco.

Discovery 7: Implement Multiarea OSPF

1 din 8 26.05.2020, 11:18

Task 2: Verify OSPF Functionality

Routing Protocol is "ospf 2"

Neighbor ID Pri State Dead Time Address Interface

Neighbor ID Pri State Dead Time Address Interface

Neighbor ID: Represents the neighbor router ID

2 din 8 26.05.2020, 11:18

Gateway of last resort is not set

172.16.0.0/16 is variably subnetted, 4 subnets, 3 masks

OSPF Router with ID (5.5.5.5) (Process ID 1)

Base Topology (MTID 0)

Intra-area Route List

Intra-area Router Path List

Interarea Route List

OSPF routers progress through seven states:

Down: No active neighbor detected

DOWN: No information has been received on the segment.

R3# clear ip ospf process

3 din 8 26.05.2020, 11:18

*Jan 17 13:02:37.396: OSPF-3 ADJ Et0/0: Elect DR 1.1.1.1

Task 3: Verify DR and BDR Election

Neighbor ID Pri State Dead Time Address Interface

4 din 8 26.05.2020, 11:18

4.4.4.4 1 FULL/BDR 00:00:37 172.16.145.4 Ethernet0/1

Neighbor ID Pri State Dead Time Address Interface

Neighbor ID Pri State Dead Time Address Interface

Neighbor ID Pri State Dead Time Address Interface

Neighbor ID Pri State Dead Time Address Interface

Neighbor ID Pri State Dead Time Address Interface

Neighbor ID Pri State Dead Time Address Interface

Neighbor ID Pri State Dead Time Address Interface

5 din 8 26.05.2020, 11:18

Neighbor ID Pri State Dead Time Address Interface

Neighbor ID Pri State Dead Time Address Interface

Neighbor ID Pri State Dead Time Address Interface

Task 4: Examine MTU-Related OSPF Issues

6 din 8 26.05.2020, 11:18

Neighbor ID Pri State Dead Time Address Interface

Neighbor ID Pri State Dead Time Address Interface

R1# show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface

Task 5: Modify OSPF Timers

R1# show ip ospf interface Serial 2/0

7 din 8 26.05.2020, 11:18

Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost: 64

© 2020 Cisco Systems, Inc.

8 din 8 26.05.2020, 11:18

You might also like