Section 12 – OSPF Basics

Section 12 Tasks

  • Read today’s theory notes
  • Review yesterday’s theory notes

Previous versions of the CCNA exam required only a basic understanding of OSPF. The current version now requires a deeper understanding of OSPFv2, v3, and multi-area OSPF. The requirements are split across the ICND1 and 2 exams and increase in difficulty on the second exam.

Today you will learn about the following:

  • Link State fundamentals
  • OSPF network types
  • Configuring OSPF

This module maps to the following CCNA syllabus requirement:

  • Configure and verify OSPF (single area)
    • Benefit of single area
    • Configure OSPFv2
    • Router ID
    • Passive interface

Open Shortest Path First

Open Shortest Path First (OSPF) is an open-standard Link State routing protocol. Link State routing protocols advertise the state of their links. When a Link State router begins operating on a network link, information associated with that logical network is added to its local Link State Database (LSDB). The local router then sends Hello messages on its operational links to determine whether other Link State routers are operating on the interfaces as well. OSPF runs directly over Internet Protocol using IP protocol number 89.

OSPF Overview and Fundamentals

Several Requests for Comments (RFCs) have been written for OSPF. In this section, we will learn about the history of OSPF based on some of the most common RFCs that pertain to OSPF. The OSPF working group was formed in 1987 and it has since released numerous RFCs. Some of the most common RFCs on OSPF are listed below:

  • RFC 1131 – OSPF Specification
  • RFC 1584 – Multicast Extensions to OSPF
  • RFC 1587 – The OSPF NSSA Option
  • RFC 1850 – OSPF Version 2 Management Information Base
  • RFC 2328 – OSPF Version 2
  • RFC 2740 – OSPF Version 3

RFC 1131 describes the first iteration of OSPF, and it was used in initial tests to determine whether the protocol worked.

RFC 1584 provides extensions to OSPF for the support of IP Multicast traffic. This is commonly referred to as Multicast OSPF (MOSPF). However, this standard is seldom used and, most importantly, it is not supported by Cisco.

RFC 1587 describes the operation of an OSPF Not-So-Stubby Area (NSSA). An NSSA allows for the injection of external routing knowledge by an Autonomous System Boundary Router (ASBR) using an NSSA External LSA. NSSAs will be described in detail later in this module.

RFC 1850 allows network management of OSPF using the Simple Network Management Protocol (SNMP). SNMP is used in network management systems to monitor network-attached devices for conditions that warrant administrative attention. The implementation of this standard is beyond the scope of the CCNA exam requirements and is not described in this guide.

RFC 2328 details the latest update to OSPF version 2 (OSPFv2), which is the default version of OSPF in use today. OSPFv2 was initially described in RFC 1247, which addressed a number of issues discovered during the initial rollout of OSPF version 1 (OSPFv1) and modified the protocol to allow future modifications without generating backward-compatibility issues. Because of this, OSPFv2 is not compatible with OSPFv1.

Finally, RFC 2740 describes the modifications to OSPF to support IPv6. It should be assumed that all references to OSPF in this module are for OSPFv2.

When a Link State routing protocol is enabled for a particular link, information associated with that network is added to the local Link State Database (LSDB). The local router then sends Hello messages on its operational links to determine whether other Link State routers are operating on the interfaces as well. The Hello messages are used for neighbour discovery and to maintain adjacencies between neighbour routers. These messages will be described in detail later in this module.

When a neighbour router is located, the local router attempts to establish an adjacency, assuming both routers share the same common subnet, are in the same area, and that other parameters, such as authentication and timers, are identical. This adjacency enables the two routers to advertise summary LSDB information to each other. This exchange is not the actual detailed database information but is instead a summary of the data.

Each individual router evaluates the summary information against its local LSDB to ensure that it has the most up-to-date information. If one side of the adjacency realises that it requires an update, the router requests the new information from the adjacent router. The update from the neighbour includes the actual data contained in the LSDB. This exchange process continues until both routers have identical LSDBs. OSPF uses different types of messages to exchange the database information and to ensure that all routers have a consistent view of the network. These different packet types will be described in detail later in this module.

Following the database exchange, the SPF algorithm runs and creates a shortest-path tree to all hosts in an area or in the network backbone, with the router that is performing the calculation at the root of that tree. The SPF algorithm was described briefly in Day 10.

OSPF Fundamentals

Unlike EIGRP, which can support multiple Network Layer protocols, OSPF can only support the Internet Protocol (IP), specifically IPv4 and IPv6. Like EIGRP, OSPF supports VLSM and authentication and utilises IP Multicast when sending and receiving updates on Multi-Access networks, such as Ethernet.

OSPF is a hierarchical routing protocol that logically divides the network into subdomains referred to as areas. This logical segmentation is used to limit the scope of Link State Advertisements (LSAs) flooding throughout the OSPF domain. LSAs are special types of packets sent by routers running OSPF. Different types of LSAs are used within an area and between areas. By restricting the propagation of certain types of LSAs between areas, the OSPF hierarchical implementation effectively reduces the amount of routing protocol traffic within the OSPF network.

NOTE: OSPF LSAs will be described in detail in Day 39.

In a multi-area OSPF network, one area must be designated as the backbone area, or Area 0. The OSPF backbone is the logical centre of the OSPF network. All other non-backbone areas must be connected physically to the backbone. However, because it is not always possible or feasible to have a physical connection between a non-backbone area and the backbone, the OSPF standard allows the use of virtual connections to the backbone. These virtual connections are known as virtual links, but this concept is not included in the current CCNA syllabus.

Routers within each area store detailed topology information for the area in which they reside. Within each area, one or more routers, referred to as Area Border Routers (ABRs), facilitate inter-area routing by advertising summarised routing information between the different areas. This functionality allows for the following within the OSPF network:

  • Reduces the scope of LSAs flooding throughout the OSPF domain
  • Hides detailed topology information between areas
  • Allows for end-to-end connectivity within the OSPF domain
  • Creates logical boundaries within the OSPF domain

NOTE: Although the ICND1 syllabus makes reference only to single-area OSPF, it is necessary to discuss multi-area OSPF in order to put much of the theory into context.

The OSPF backbone area receives summarised routing information from the ABRs. The routing information is disseminated to all other non-backbone areas within the OSPF network. When a change to the network topology occurs, this information is disseminated throughout the entire OSPF domain, allowing all routers in all areas to have a consistent view of the network. The network topology illustrated in Figure 12.1 below is an example of a multi-area OSPF implementation:

Section 12 – OSPF Basics 3

Figure 12.1 – A Multi-Area OSPF Network

Figure 12.1 illustrates a basic multi-area OSPF network. Areas 1 and 2 are connected to Area 0, the OSPF backbone. Within Area 1, routers R1, R2, and R3 exchange intra-area routing information and maintain detailed topology for that area. R3, the ABR, generates an inter-area summary route and advertises this to the OSPF backbone.

R4, the ABR for Area 2, receives the summary information from Area 0 and floods it into its adjacent area. This allows routers R5 and R6 to know of the routes that reside outside of their local area but within the OSPF domain. The same concept would also be applicable to the routing information within Area 2.

In summation, the ABRs maintain LSDB information for all the areas in which they are connected. All routers within each area have detailed topology information pertaining to that specific area. These routers exchange intra-area routing information. The ABRs advertise summary information from each of their connected areas to other OSPF areas, allowing for inter-area routing within the domain.

NOTE: OSPF ABRs and other OSPF router types will be described in detail later in this guide.

Network Types

OSPF uses different default network types for different media, which are as follows:

  • Non-Broadcast (default on Multipoint NBMA (FR and ATM))
  • Point-to-Point (default on HDLC, PPP, P2P subinterface on FR and ATM, and ISDN)
  • Broadcast (default on Ethernet and Token Ring)
  • Point-to-Multipoint
  • Point-to-Multipoint Non-Broadcast
  • Loopback (default on Loopback interfaces)

Non-Broadcast networks are network types that do not support natively Broadcast or Multicast traffic. The most common example of a Non-Broadcast network type is Frame Relay. Non- Broadcast network types require additional configuration to allow for both Broadcast and Multicast support. On such networks, OSPF elects a Designated Router (DR) and/or a Backup Designated Router (BDR). These two routers are described later in this guide.

In Cisco IOS software, OSPF-enabled routers send Hello packets every 30 seconds by default on Non-Broadcast network types. If a Hello packet is not received in four times the Hello interval, or 120 seconds, the neighbour router is considered “dead.” The following output illustrates the show ip ospf interface command on a Frame Relay Serial interface:

R2#show ip ospf interface Serial0/0
Serial0/0 is up, line protocol is up
Internet Address 150.1.1.2/24, Area 0
Process ID 2, Router ID 2.2.2.2, Network Type NON_BROADCAST, Cost: 64
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 2.2.2.2, Interface address 150.1.1.2
Backup Designated Router (ID) 1.1.1.1, Interface address 150.1.1.1
Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
oob-resync timeout 120
Hello due in 00:00:00
Supports Link-local Signaling (LLS)
Index 2/2, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 2, maximum is 2
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 1.1.1.1  (Backup Designated Router)
Suppress Hello for 0 neighbor(s)

A Point-to-Point (P2P) connection is simply a connection between two endpoints only. Examples of P2P connections include physical WAN interfaces using HDLC and PPP encapsulation, and Frame Relay (FR) and Asynchronous Transfer Mode (ATM) Point-to-Point subinterfaces. No DR or BDR is elected on OSPF Point-to-Point network types. By default, OSPF sends Hello packets out every 10 seconds on P2P network types. The “dead” interval on these network types is four times the Hello interval, which is 40 seconds. The following output illustrates the show ip ospf interface command on a P2P link:

R2#show ip ospf interface Serial0/0
Serial0/0 is up, line protocol is up
Internet Address 150.1.1.2/24, Area 0
Process ID 2, Router ID 2.2.2.2, Network Type POINT_TO_POINT, Cost: 64
Transmit Delay is 1 sec, State POINT_TO_POINT
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:03
Supports Link-local Signaling (LLS)
Index 2/2, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 1
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 1.1.1.1
Suppress Hello for 0 neighbor(s)

Broadcast network types are those that natively support Broadcast and Multicast traffic, the most common example being Ethernet. As is the case with Non-Broadcast networks, OSPF also elects a DR and/or a BDR on Broadcast networks. By default, OSPF sends Hello packets every 10 seconds on these network types and a neighbour is declared “dead” if no Hello packets are received within four times the Hello interval, which is 40 seconds. The following output illustrates the show ip ospf interface command on a FastEthernet interface:

R2#show ip ospf interface FastEthernet0/0
FastEthernet0/0 is up, line protocol is up
Internet Address 192.168.1.2/24, Area 0
Process ID 2, Router ID 2.2.2.2, Network Type BROADCAST, Cost: 64
Transmit Delay is 1 sec, State BDR, Priority 1
Designated Router (ID) 192.168.1.3, Interface address 192.168.1.3
Backup Designated Router (ID) 2.2.2.2, Interface address 192.168.1.2
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:04
Supports Link-local Signaling (LLS)
Index 1/1, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 1
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 192.168.1.3  (Designated Router)
Suppress Hello for 0 neighbor(s)

Point-to-Multipoint is a non-default OSPF network type. In other words, this network type must be configured manually using the ip ospf network point-to-multipoint [non-broadcast] interface configuration command. By default, this command defaults to a Broadcast Point-to-
Multipoint network type. This default network type allows OSPF to use Multicast packets to discover dynamically its neighbour routers. In addition, there is no DR/BDR election held on Broadcast Point-to-Multipoint network types.

The [non-broadcast] keyword configures the Point-to-Multipoint network type as a Non- Broadcast Point-to-Multipoint network. This requires static OSPF neighbour configuration, as OSPF will not use Multicast to discover dynamically its neighbour routers. Additionally, this network type does not require the election of a DR and/or a BDR router for the designated segment. The primary use of this network type is to allow neighbour costs to be assigned to neighbours instead of using the interface-assigned cost for routes received from all neighbours.

The Point-to-Multipoint network type is typically used in partial-mesh hub-and-spoke Non- Broadcast Multi-Access (NBMA) networks. However, this network type can also be specified for other network types, such as Broadcast Multi-Access networks (e.g., Ethernet). By default, OSPF sends Hello packets every 30 seconds on Point-to-Multipoint networks. The default dead interval is four times the Hello interval, which is 120 seconds.

The following output illustrates the show ip ospf interface command on a Frame Relay Serial interface that has been configured manually as a Point-to-Multipoint network:

R2#show ip ospf interface Serial0/0
Serial0/0 is up, line protocol is up
Internet Address 150.1.1.2/24, Area 0
Process ID 2, Router ID 2.2.2.2, Network Type POINT_TO_MULTIPOINT, Cost: 64
Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT
Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
oob-resync timeout 120
Hello due in 00:00:04
Supports Link-local Signaling (LLS)
Index 2/2, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 2
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 1.1.1.1
Suppress Hello for 0 neighbor(s)

The primary reason for the OSPF requirement that the network type be the same on both routers (by the same this means that they either hold or don’t hold elections) is because of the timer values. As illustrated in the outputs above, different network types use different Hello and Dead timer intervals. In order for an OSPF adjacency to be established successfully, these values must match on both routers.

Cisco IOS software allows the default OSPF Hello and Dead timers to be changed using the ip ospf hello-interval <1-65535> and the ip ospf dead-interval [<1-65535>|minimal] interface configuration commands. The ip ospf hello-interval <1-65535> command is used to specify the Hello interval in seconds. When issued, the software automatically configures the Dead interval to a value four times the configured Hello interval. For example, assume that a router was configured as follows:

R2(config)#interface Serial0/0
R2(config-if)#ip ospf hello-interval 1
R2(config-if)#exit

By setting the Hello interval to 1 on R2 above, Cisco IOS software automatically adjusts the default Dead timer to four times the Hello interval, which is 4 seconds. This is illustrated in the following output:

R2#show ip ospf interface Serial0/0
Serial0/0 is up, line protocol is up
Internet Address 10.0.2.4/24, Area 2
Process ID 4, Router ID 4.4.4.4, Network Type POINT_TO_POINT, Cost: 64
Transmit Delay is 1 sec, State POINT_TO_POINT
Timer intervals configured, Hello 1, Dead 4, Wait 4, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:00
...
[Truncated Output]

OSPF Configuration

This section describes OSPF configuration fundamentals.

Enabling OSPF in Cisco IOS Software

OSPF is enabled in Cisco IOS software by issuing the router ospf [process id] global configuration command. The [process id] keyword is locally significant and does not need to be the same on all routers in the network in order to establish an adjacency. The use of the locally significant process ID allows you to configure multiple instances of OSPF on the same router.

The OSPF process ID is an integer between 1 and 65535. Each OSPF process maintains its own separate Link State Database; however, all routes are entered into the same IP routing table. In other words, there is no unique IP routing table for each individual OSPF process configured on the router.

In earlier versions of Cisco IOS software, OSPF would not be enabled if the router did not have at least one interface configured with a valid IP address in the up/up state. This restriction has been removed in current versions of Cisco IOS software. In the event that the router has no interfaces configured with a valid IP address and in the up/up state, Cisco IOS will create a Proximity Database (PDB) and allow the process to be created. However, it is important to remember that the process will be inactive until a router ID is selected, which can be performed in the following two ways:

  • Configuring a valid IP address on an interface and bringing the interface up
  • Configuring the router ID manually using the router-id command (see below)

As an example, consider the following router, which has all interfaces disabled:

R3#show ip interface brief
Interface        IP-Address   OK? Method Status                Protocol
FastEthernet0/0  unassigned   YES manual administratively down down
Serial0/0        unassigned   YES NVRAM  administratively down down
Serial0/1        unassigned   YES unset  administratively down down

Next, OSPF is enabled on the router using the router ospf [process id] global configuration command, as illustrated in the following output:

R3(config)#router ospf 1
R3(config-router)#exit

Based on this configuration, Cisco IOS software assigns the process a default router ID of 0.0.0.0, as illustrated in the following output of the show ip protocols command:

R3#show ip protocols
Routing Protocol is “ospf 1”
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID 0.0.0.0
Number of areas in this router is 0. 0 normal 0 stub 0 nssa
Maximum path: 4
Routing for Networks:
Reference bandwidth unit is 100 mbps
Routing Information Sources:
Gateway         Distance      Last Update
Distance: (default is 110)

However, the show ip ospf [process id] command reveals that the process is not actually active and indicates that a router ID needs to be configured, as illustrated below:

R3#show ip ospf 1
%OSPF: Router process 1 is not running, please configure a router-id

Enabling OSPF Routing for Interfaces or Networks

After OSPF has been enabled, two actions can be performed to enable OSPF routing for one or more networks or interfaces on the router, as follows:

  • Using the [network] [wildcard] area [area id] router configuration command
  • Using the ip ospf [process id] area [area id] interface configuration command

Unlike EIGRP, the wildcard mask is mandatory in OSPF and must be configured; however, as is the case with EIGRP, it serves the same function in that it matches interfaces within the range specified. As an example, the statement network 10.0.0.0 0.255.255.255 area 0 would enable OSPF routing for interfaces with the IP address and subnet mask combination of 10.0.0.1/30, 10.5.5.1/24, and even 10.10.10.1/25. The interfaces would all be assigned to OSPF Area 0 based on the OSPF network configuration.

NOTE: The wildcard mask for OSPF can also be entered in the same format as a traditional subnet mask, for example, network 10.0.0.0 255.0.0.0 area 0. In this case, Cisco IOS software will invert the subnet mask and the wildcard mask will be entered into the running configuration. In addition, it is important to remember that OSPF also supports the use of the all ones or all zeros wildcard mask to enable OSPF routing for a specific interface. This configuration enables OSPF on a particular interface but the router advertises the actual subnet mask configured on the interface itself.

After the network [network] [wildcard] area [area id] command has been issued, the router sends out Hello packets on interfaces matching the specified network and wildcard mask combination and attempts to discover neighbours. The connected subnet is then advertised to one or more neighbour routers during the OSPF database exchange, and, finally, this information is then added to the OSPF Link State Database of the OSPF routers.

When the network [network] [wildcard] area [area id] command is issued, the router matches the most specific entry in order to determine the area the interface will be assigned to. Consider the following OSPF network statement configurations, as an example:

  • First configuration statement: network 10.0.0.0 0.255.255.255 Area 0
  • Second configuration statement: network 10.1.0.0 0.0.255.255 Area 1
  • Third configuration statement: network 10.1.1.0 0.0.0.255 Area 2
  • Fourth configuration statement: network 10.1.1.1 0.0.0.0 Area 3
  • Fifth configuration statement: network 0.0.0.0 255.255.255.255 Area 4

Following this configuration on the router, the Loopback interfaces shown in Table 12.1 below are then configured on the same router:

Table 12.1 – Assigning Interfaces to OSPF Areas

Section 12 – OSPF Basics 4

As was previously stated, when the network [network] [wildcard] area [area id] command is issued, the router matches the most specific entry in order to determine the area in which the interface will be assigned. For the network statement configuration and the Loopback interfaces configured on the router, the show ip ospf interface brief command would show that the interfaces were assigned to the following OSPF areas:

R1#show ip ospf interface brief
Interface    PID   Area    IP Address/Mask    Cost  State Nbrs F/C
Lo4          1     0       10.2.0.1/32        1     LOOP  0/0
Lo1          1     0       10.0.1.1/32        1     LOOP  0/0
Lo0          1     0       10.0.0.1/32        1     LOOP  0/0
Lo2          1     1       10.1.0.1/32        1     LOOP  0/0
Lo3          1     3       10.1.1.1/32        1     LOOP  0/0

NOTE: Regardless of the order in which the network statements are entered, within the running configuration, the most specific entries are listed first in the output of the show running-config command on the router.

The ip ospf [process id] area [area id] interface configuration command negates the need to use the network [network] [wildcard] area [area id] router configuration command. This command enables OSPF routing for the specified interface and assigns the interface to the specified OSPF area. These two commands perform the same basic function and may be used interchangeably.

Additionally, if, for example, two routers are connected back to back, with one router configured using the ip ospf [process id] area [area id] interface configuration command and the neighbour router configured using the network [network] [wildcard] area [area id] router configuration command, then, assuming the area IDs are the same, the routers will successfully establish an OSPF adjacency.

OSPF Areas

The OSPF area ID may be configured either as an integer between 0 and 4294967295 or using dotted-decimal notation (i.e., using the IP address format). Unlike the OSPF process ID, the OSPF area ID must match in order for adjacency to be established. The most common type of OSPF area configuration is using an integer to specify the OSPF area. However, ensure that you are familiar with both supported methods of area configuration.

OSPF Router ID

In order for OSPF to operate on a network, each router must have a unique identifying number, and in the context of OSPF the router ID number is used.

When determining the OSPF router ID, Cisco IOS selects the highest IP address of configured Loopback interfaces. If no Loopback interfaces are configured, the software uses the highest IP address of all configured physical interfaces as the OSPF router ID. Cisco IOS software also allows administrators to specify the router ID manually using the router-id [address] router configuration command.

Loopback interfaces are very useful, especially during testing because they require no hardware and are logical, so they can never be down.

On the router below, I have configured IP address 1.1.1.1/32 for Loopback0 and 2.2.2.2/24 for F0/0. I then configured OSPF for all interfaces on the router:

Router(config-if)#router ospf 1
Router(config-router)#net 0.0.0.0 255.255.255.255 area 0
Router(config-router)#end
Router#
%SYS-5-CONFIG_I: Configured from console by console
Router#show ip protocols
Routing Protocol is “ospf 1”
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID 1.1.1.1
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Maximum path: 4
Routing for Networks:
0.0.0.0 255.255.255.255 area 0
Routing Information Sources:
Gateway         Distance      Last Update
1.1.1.1              110      00:00:14
Distance: (default is 110)

I want to hard code the router ID to 10.10.10.1. I could have done this by configuring another Loopback interface with this IP address, or I can simply add this at the OSPF router ID. I will have to either reload the router or clear the IP OSPF process on the router in order for this to take effect.

Router#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#router ospf 1
Router(config-router)#router-id 10.10.10.1
Router(config-router)#Reload or use “clear ip ospf process” command, for this to take
effect
Router(config-router)#end
Router#
%SYS-5-CONFIG_I: Configured from console by console
Router#clear ip ospf process
Reset ALL OSPF processes? [no]: yes
Router#show ip prot
Routing Protocol is “ospf 1”
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID 10.10.10.1
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Maximum path: 4
Routing for Networks:
0.0.0.0 255.255.255.255 area 0
Routing Information Sources:
Gateway         Distance      Last Update
1.1.1.1              110      00:03:15
Distance: (default is 110)

The router ID is of particular importance when it comes to electing the DR and BDR as you will see in Day 39.

OSPF Passive Interfaces

Passive interfaces can be described as interfaces over which no routing updates are sent. In Cisco IOS software, an interface is configured as passive by using the passive-interface [name] router configuration command. If there are multiple interfaces on the router that need to be configured as passive, the passive-interface default router configuration command should be used. This command configures all interfaces that fall within the configured network range on the router to be passive. Interfaces on which adjacencies or neighbour relationships should be allowed can then be configured using the no passive-interface [name] router configuration command.

Passive interface configuration works the same for both OSPF and EIGRP in that if an interface is marked as passive, all neighbour relationships via that interface will be torn down and Hello packets will not send or receive packets via that interface. However, the interface will continue to be advertised based on the configured network statement configuration on the router:

Router(config)#router ospf 10
Router(config-router)#passive-interface f0/0
Router#show ip ospf int f0/0
FastEthernet0/0 is up, line protocol is up
 Internet address is 192.168.1.1/24, Area 0
 Process ID 10,Router ID 172.16.1.1,Network Type BROADCAST, Cost: 1
 Transmit Delay is 1 sec, State WAITING, Priority 1
 No designated router on this network
 No backup designated router on this network
 Timer intervals configured,Hello 10, Dead 40, Wait 40,Retransmit 5
  No Hellos (Passive interface)

 

Section 12 Questions

1. What protocol does OSPF use?
2. How does OSPF determine whether other Link State routers are operating on the
interfaces as well?
3. When a _______ routing protocol is enabled for a particular link, information associated
with that network is added to the local Link State Database (LSDB).
4. OSPF utilises IP Multicast when sending and receiving updates on Multi-Access networks,
such as Ethernet. True or false?
5. OSPF is a hierarchical routing protocol that logically divides the network into subdomains
referred to as _______.
6. Name at least 4 OSPF network types.
7. Name the command used to enter OSPF configuration mode.
8. When determining the OSPF router ID, Cisco IOS selects the lowest IP address of the
configured Loopback interfaces. True or false?
9. What command can you use to assign an interface to OSPF Area 2 (interface level
command)?
10. _______ can be described as interfaces over which no routing updates are sent.

Section 12 Answers

1. IP number 89.
2. By sending Hello packets.
3. Link State.
4. True.
5. Areas.
6. Non-Broadcast, Point-to-Point, Broadcast, Point-to-Multipoint, Point-to-Multipoint Non-
Broadcast, and Loopback.
7. The router ospf <id> command.
8. False.
9. The ip ospf <id> area 2 command.
10. Passive.

Section 12 Lab

Basic OSPF Lab

Repeat the scenario from Day 10 (two routers directly connected, Loopback interface on each of them) but instead of configuring RIP and advertising the physical and Loopback interfaces, do this using OSPF Area 0:

  • Assign an IPv4 address to the directly connected interfaces (10.10.10.1/24 and 10.10.10.2/24)
  • Test direct connectivity using ping
  • Configure a Loopback interface on each router and assign addresses from two different ranges (11.11.11.1/32 and 12.12.12.2/32)
  • Configure standard OSPF process 1 and advertise all the local networks in Area 0. Also, configure a router ID for each device:

R1:

router ospf 1
router-id 1.1.1.1
network 10.10.10.0 0.0.0.255 area 0
network 11.11.11.1 0.0.0.0 area 0

R2:

router ospf 1
router-id 2.2.2.2
network 10.10.10.0 0.0.0.255 area 0
network 12.12.12.2 0.0.0.0 area 0
  • Ping R2 Loopback from R1 to test connectivity
  • Issue a show ip route command to verify that routes are being received via OSPF
  • Issue a show ip protocols command to verify that OSPF is configured and active on the devices
  • Verify the interface OSPF-specific parameters: show ip ospf interface and show ip ospf interface brief
  • Change the OSPF Hello and Dead timers on both routers (directly connected interfaces): ip ospf hello and ip ospf dead
  • Issue a show ip ospf 1 command to see the routing process parameters
  • Repeat the lab but this time advertise the networks in OSPF using the ip ospf 1 area 0 interface specific command instead of the network command under router OSPF

Subscribe
Notify of
guest

0 Comments
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x