Tasks
Note: You must perform Lab0 for loading the initial configurations before starting this lab.
● Configure OSPF using process ID of 1 on R6, R7, and R9 as follows:
✓ Use only interface-level commands on R9.
✓ Do not use any interface-level commands on R6 and R7.
✓ Use area 67 between R6 and R7, and area 79 between R7 and R9.
✓ Advertise Loopback0 prefixes of R6 in area 67 and Loopback0 of R9 in area 79.
● On R6, enable OSPF only for interfaces with the exact IP addresses of 170.1.6.6 and 177.1.67.6.
● On R7, enable OSPF on all interfaces within the subnets 177.1.67.0/24 and 177.1.79.0/24.
● Ensure that R7 has IP connectivity with R6's and R9's Loopback0 prefixes.
Configurations
R6:
enable
!
configure terminal
!
router ospf 1
network 177.1.67.6 0.0.0.0 area 67
network 170.1.6.6 0.0.0.0 area 67
!
end
!
write
!
R7:
enable
!
configure terminal
!
router ospf 1
network 177.1.67.0 0.0.0.255 area 67
network 177.1.79.0 0.0.0.255 area 79
!
end
!
write
!
R9:
enable
!
configure terminal
!
interface GigabitEthernet0/0
ip ospf 1 area 79
!
interface Loopback0
ip ospf 1 area 79
!
end
!
write
!
Verifications
This task illustrates two different ways to enable the OSPF process. These include the legacy network statement under the OSPF process and the interface-level command ip ospf [process-id] area [area-id]. Both accomplish the same thing with one minor exception. If an interface is IP unnumbered, and there is a network statement that matches the IP address of the primary interface, both the primary interface and the unnumbered interface will have OSPF enabled on them in the designated area. Additionally, when enabled at the interface level, by default OSPF will inject both primary and secondary subnets of the interface in the OSPF database and advertise it to its neighbors. If you want to suppress the secondary prefixes, use the ip ospf [process-id] area [area-id] secondaries none command.
The network statement in OSPF, just like the network statement under the EIGRP process, is not used to originate a network advertisement. Instead it simply enables the OSPF process on the interface. If multiple network statements overlap the same interface, the most specific match based on the wildcard mask wins.
R6 enables the OSPF area 67 only on the interface with the exact IP address of 177.1.67.6 with the command network 177.1.67.6 0.0.0.0 area 67 , which does not mean, however, that the network 177.1.67.6/32 itself will be advertised. Instead, OSPF will read the prefix from the interface configuration and bring the 177.1.67.0/24 subnet in the OSPF database.
Likewise on R7, the network 177.1.67.0 0.0.0.255 area 67 command means that OSPF area 67 will be enabled on any interface within the 177.1.67.0/24 subnet. It is just a coincidence that the network command actually also matches the prefix-length/subnet-mask.
Regardless of whether the network statement or the ip ospf statement are used, the result can be verified with the show ip ospf interface brief command. Note that in the output below, there is no functional difference seen between R6 and R9, which had OSPF enabled differently.
R6#show ip ospf interface brief
R9#show ip ospf interface brief
There is, however, a detailed output that identifies how OSPF was enabled for that interface, with or without the network command.
R6#show ip ospf interface gigabitEthernet0/1
R9#show ip ospf interface gigabitEthernet0/0
After verifying that the interfaces are configured in the correct areas, the next verification is to check the adjacency state of the OSPF neighbors with the show ip ospf neighbor command. To form an OSPF adjacency, some attributes must match between neighbors, while others must be unique. The common attributes that must match are the area number, timers, authentication, stub flags, MTU, and compatible network types. The attributes that must be unique are the interface IP addresses and the router-ids.
The router-id is a 32-bit number and is chosen first based on the process-level router-id command, second based on the highest active Loopback IP interface, and last based on the highest active non-Loopback interface IP address. Because the LSA origination is based on the router-id, each router needs a unique OSPF router-id within the OSPF domain; otherwise OSPF database collisions occur and the SPF tree cannot be properly calculated. Moreover, two routers with the same router-id cannot become neighbors, for the same exact reason; basically the router is saying, I can't become neighbor with myself.
Verify that R7 is OSPF neighbor with both R6 and R9, and reached a functional neighbor state. For this case, where there are only two neighbors on the broadcast segment, a functional state means the FULL state.
R6#show ip ospf neighbor
R7#show ip ospf neighbor
R9#show ip ospf neighbor
Although adjacencies have been established, a fundamental underlying design issue still exists in the network. At this point, only areas 67 and 79 are configured.
The backbone area 0 is not configured on any links. This implies that the devices can route within their own area (Intra-Area), but not between areas (Inter-Area). This is because the Area Border Router (ABR) that connects one area to area zero is responsible for generating the Network Summary LSA (LSA 3) that describes the inter-area routes.
The result of this can be seen by viewing both the OSPF database table and the routing tables of the routers. Because R7 is attached to both areas, it has router LSAs from both areas, whereas R6 and R9 only from the areas being attached to.
R6#show ip ospf database
R7#show ip ospf database
R9#show ip ospf database
Because R7 is not configured as ABR to perform LSA1 to LSA3 translation, R6 and R9 actually learn no routes through OSPF, as R7 does not advertise any prefixes in area 67 or area 79 other than the directly connected Ethernet link with R6 and R9.
R6#show ip route ospf
R6#
R9#show ip route ospf
R9#
R7#show ip route ospf
Verify that R7 has IP connectivity with R6's and R9's Loopback0 prefixes.
R7#ping 170.1.6.6
R7#ping 170.1.9.9
