annotations: - border_color: '#00000000' border_style: '' color: '#000000' rotation: 0 text_bold: true text_content: 'CCNA Exam Prep: Back to Networking Basics with Hank Preston and Patrick Gargano' text_font: monospace text_italic: false text_size: 12 text_unit: pt thickness: 1 type: text x1: -438.0 y1: -266.0 z_index: 0 - border_color: '#00000000' border_style: '' color: '#000000' rotation: 0 text_bold: true text_content: 'Conquering OSPF: Optimize Your Network with OSPF' text_font: monospace text_italic: false text_size: 18 text_unit: pt thickness: 1 type: text x1: -438.0 y1: -241.0 z_index: 0 - border_color: '#00000000' border_style: '' color: '#000000' rotation: 0 text_bold: false text_content: |- OSPF, or Open Shortest Path First, is a widely deployed standard routing protocol that scales from small "single area" networks to large global wide area networks. CCNA candidates need to be comfortable configuring and verifying single area OSPFv2 deployments. In this lab we will explore: * Configuring IOS routers to run OSPF and share network information with neighbors * Configure and verify neighbor adjacency details such as, Router IDs and Timers * Designated Router/Backup Designated Router * Sharing a default route with OSPF text_font: monospace text_italic: false text_size: 12 text_unit: pt thickness: 1 type: text x1: -437.415294010199 y1: -208.7376460917897 z_index: 0 - border_color: '#808080FF' border_radius: 0 border_style: '' color: '#C5EEFF' thickness: 1 type: rectangle x1: 49.3683970210723 y1: 48.72779229141973 x2: 630.6316029789275 y2: 167.18451799163688 z_index: 0 - border_color: '#00000000' border_style: '' color: '#808080FF' rotation: 0 text_bold: false text_content: |- Building 1 Networks vl10 users 192.168.11.0/24 vl20 iot 192.168.199.0/24 vl30 security 10.1.1.0/24 vl40 guests 10.11.0.0/20 text_font: monospace text_italic: false text_size: 10 text_unit: pt thickness: 1 type: text x1: 334.97174787984807 y1: 75.84118114448668 z_index: 2 - border_color: '#D5FFD2' border_style: '' color: '#D5FFD2' thickness: 1 type: ellipse x1: 97.16925052641605 y1: 287.9891925339368 x2: 38.272718826033774 y2: 35.879856189892564 z_index: 3 - border_color: '#D5FFD2' border_style: '' color: '#D5FFD2' thickness: 1 type: ellipse x1: 143.61682664305926 y1: 261.2726717190459 x2: 35.204913397244695 y2: 33.16767687685274 z_index: 3 - border_color: '#D5FFD2' border_style: '' color: '#D5FFD2' thickness: 1 type: ellipse x1: 245.7345239243876 y1: 296.1640163661116 x2: 35.12777245494142 y2: 34.92363470866556 z_index: 3 - border_color: '#D4FFD200' border_radius: 20 border_style: '' color: '#D5FFD2' thickness: 1 type: rectangle x1: 76.26746981358835 y1: 275.4724513932729 x2: 163.73253018641165 y2: 55.558665018421436 z_index: 4 - border_color: '#D5FFD2' border_style: '' color: '#D5FFD2' thickness: 1 type: ellipse x1: 202.49992066824285 y1: 261.8532835305447 x2: 39.36374036126641 y2: 37.352572857961945 z_index: 3 - border_color: '#00000000' border_style: '' color: '#808080FF' rotation: 0 text_bold: false text_content: Building 2 text_font: monospace text_italic: false text_size: 12 text_unit: pt thickness: 1 type: text x1: 97.45800926863043 y1: 284.96097970934585 z_index: 5 - border_color: '#808080FF' border_style: '' color: '#FFFFFFFF' line_end: null line_start: null thickness: 2 type: line x1: -40.0 y1: 120.0 x2: 80.0 y2: 280.0 z_index: 1 - border_color: '#00000000' border_style: '' color: '#808080FF' rotation: 0 text_bold: false text_content: 10.11.15.1 text_font: monospace text_italic: false text_size: 8 text_unit: pt thickness: 1 type: text x1: 209.89880484388777 y1: 204.26761748761922 z_index: 6 - border_color: '#00000000' border_style: '' color: '#808080FF' rotation: 0 text_bold: false text_content: 192.168.11.101 text_font: monospace text_italic: false text_size: 8 text_unit: pt thickness: 1 type: text x1: 197.49768726441954 y1: 122.83010690662928 z_index: 6 - border_color: '#808080FF' border_radius: 0 border_style: '' color: '#C0C0C0' thickness: 1 type: rectangle x1: -309.95355209528157 y1: 31.260753098263688 x2: 296.93966628365354 y2: 256.1832414996226 z_index: 0 - border_color: '#00000000' border_style: '' color: '#FFFFFF' rotation: 0 text_bold: true text_content: Campus Core text_font: monospace text_italic: false text_size: 14 text_unit: pt thickness: 1 type: text x1: -303.7474893399314 y1: 262.2316048585568 z_index: 2 - border_color: '#00000000' border_style: '' color: '#2D39C2' rotation: 0 text_bold: true text_content: |- Core Routing 172.20.1.0/24 text_font: monospace text_italic: false text_size: 6 text_unit: pt thickness: 1 type: text x1: -76.49666902463494 y1: 153.0613194653771 z_index: 6 - border_color: '#00000000' border_style: '' color: '#2D39C2' rotation: 89 text_bold: true text_content: 172.20.0.0/30 text_font: monospace text_italic: false text_size: 4 text_unit: pt thickness: 1 type: text x1: -141.35413914042374 y1: 124.37305427271227 z_index: 6 - border_color: '#00000000' border_style: '' color: '#F70606' rotation: 0 text_bold: false text_content: Primary text_font: monospace text_italic: false text_size: 10 text_unit: pt thickness: 1 type: text x1: -188.71318984911622 y1: 43.706313383543275 z_index: 7 - border_color: '#00000000' border_style: '' color: '#DD8888' rotation: 0 text_bold: false text_content: Backup text_font: monospace text_italic: false text_size: 10 text_unit: pt thickness: 1 type: text x1: -182.95464318244893 y1: 241.65323840327255 z_index: 7 - border_color: '#03A717' border_radius: 5 border_style: 4,2 color: '#FFFFFF00' thickness: 5 type: rectangle x1: -168.5 y1: 70.04382553738856 x2: 289.0 y2: 135.0 z_index: 1 - border_color: '#00000000' border_style: '' color: '#008821' rotation: 0 text_bold: true text_content: OSPF Area 0 text_font: monospace text_italic: false text_size: 12 text_unit: pt thickness: 1 type: text x1: -40.417540054179206 y1: 80.34477611549127 z_index: 8 nodes: - boot_disk_size: null configuration: - name: ios_config.txt content: |- hostname cr-rtr1 ! ! In order to avoid entering a configuration dialog ! on boot, please ensure that all ethernet interfaces ! have some ip configuration present here such as the ! example below: ! interface range Ethernet 0/0 - 3 no ip address shutdown ! interface e0/0 description Connection to Internet ip address dhcp ip nat outside no shutdown exit interface e0/1 description Connection to cr-rtr2 ip address 172.20.0.1 255.255.255.252 ip nat inside no shutdown exit interface e0/2 description Connection to Campus Core Switch ip address 172.20.1.1 255.255.255.0 ip nat inside no shutdown exit ! interface loop99 ip address 192.168.200.1 255.255.255.255 no shutdown exit ! ip nat inside source list 1 interface Ethernet0/0 overload ! ip access-list standard 1 10 permit 0.0.0.0 255.255.255.255 ! ! ip route 192.168.11.0 255.255.255.0 172.20.1.11 ip route 192.168.199.0 255.255.255.0 172.20.1.11 ip route 10.1.1.0 255.255.255.0 172.20.1.11 ip route 10.11.0.0 255.255.248.0 172.20.1.11 ! end cpu_limit: null cpus: null data_volume: null hide_links: false id: n0 image_definition: null label: cr-rtr1 node_definition: iol-xe parameters: {} ram: null tags: [] x: -160 y: 80 interfaces: - id: i0 label: Loopback0 type: loopback - id: i1 label: Ethernet0/0 slot: 0 type: physical - id: i2 label: Ethernet0/1 slot: 1 type: physical - id: i3 label: Ethernet0/2 slot: 2 type: physical - id: i4 label: Ethernet0/3 slot: 3 type: physical - boot_disk_size: null configuration: - name: ios_config.txt content: |- hostname cr-rtr2 ! ! In order to avoid entering a configuration dialog ! on boot, please ensure that all ethernet interfaces ! have some ip configuration present here such as the ! example below: ! interface range Ethernet 0/0 - 3 no ip address shutdown ! interface e0/0 description Connection to Internet ip address dhcp ip nat outside no shutdown exit interface e0/1 description Connection to cr-rtr1 ip address 172.20.0.2 255.255.255.0 ip nat inside no shutdown exit interface e0/2 description Connection to Campus Core Switch ip address 172.20.1.2 255.255.255.0 ip nat inside no shutdown exit ! ip nat inside source list 1 interface Ethernet0/0 overload ! ip access-list standard 1 10 permit 0.0.0.0 255.255.255.255 ! ! ip route 192.168.11.0 255.255.255.0 172.20.1.11 ip route 192.168.199.0 255.255.255.0 172.20.1.11 ip route 10.1.1.0 255.255.255.0 172.20.1.11 ip route 10.11.0.0 255.255.240.0 172.20.1.11 ! ! Configure default route through cr-rtr1, backup DHCP to internet ! SLA tracking against reachability to cr-rtr1 Int e0/1 IP setup ! because IOL interface doesn't go "down" when disconnected. ip sla 1 icmp-echo 172.20.0.1 source-interface Ethernet0/1 threshold 800 timeout 1000 frequency 2 ip sla schedule 1 life forever start-time now track 1 ip sla 1 reachability ip route 0.0.0.0 0.0.0.0 172.20.0.1 track 1 ! end cpu_limit: null cpus: null data_volume: null hide_links: false id: n1 image_definition: null label: cr-rtr2 node_definition: iol-xe parameters: {} ram: null tags: [] x: -160 y: 201 interfaces: - id: i0 label: Loopback0 type: loopback - id: i1 label: Ethernet0/0 slot: 0 type: physical - id: i2 label: Ethernet0/1 slot: 1 type: physical - id: i3 label: Ethernet0/2 slot: 2 type: physical - id: i4 label: Ethernet0/3 slot: 3 type: physical - boot_disk_size: null configuration: - name: ios_config.txt content: |- hostname bld1-sw ! vtp mode transparent ! vlan 10 name users vlan 20 name iot vlan 30 name security vlan 40 name guests ! interface vlan 10 ip address 192.168.11.1 255.255.255.0 no shutdown exit interface vlan 20 ip address 192.168.199.1 255.255.255.0 no shutdown exit interface vlan 30 ip address 10.1.1.1 255.255.255.0 no shutdown exit interface vlan 40 ip address 10.11.0.1 255.255.240.0 no shutdown exit ! interface e0/0 no switchport description Connection to Campus Core Switch ip address 172.20.1.11 255.255.255.0 no shutdown interface e0/1 description Link to User 1 switchport mode access switchport access vlan 10 spanning-tree portfast no shutdown interface e0/2 description Link to Guest 1 switchport mode access switchport access vlan 40 spanning-tree portfast no shutdown interface e0/3 description Configured as Trunk to bring up all VLANs switchport trunk encap dot1q switchport mode trunk no shutdown ! ip routing ip route 0.0.0.0 0.0.0.0 172.20.1.1 ip route 0.0.0.0 0.0.0.0 172.20.1.2 10 ! end cpu_limit: null cpus: null data_volume: null hide_links: false id: n2 image_definition: null label: bld1-sw node_definition: ioll2-xe parameters: {} ram: null tags: [] x: 80 y: 120 interfaces: - id: i0 label: Loopback0 type: loopback - id: i1 label: Ethernet0/0 slot: 0 type: physical - id: i2 label: Ethernet0/1 slot: 1 type: physical - id: i3 label: Ethernet0/2 slot: 2 type: physical - id: i4 label: Ethernet0/3 slot: 3 type: physical - boot_disk_size: null configuration: [] cpu_limit: null cpus: null data_volume: null hide_links: false id: n3 image_definition: null label: int-sw node_definition: unmanaged_switch parameters: {} ram: null tags: [] x: -280 y: 120 interfaces: - id: i0 label: port0 slot: 0 type: physical - id: i1 label: port1 slot: 1 type: physical - id: i2 label: port2 slot: 2 type: physical - id: i3 label: port3 slot: 3 type: physical - id: i4 label: port4 slot: 4 type: physical - id: i5 label: port5 slot: 5 type: physical - id: i6 label: port6 slot: 6 type: physical - id: i7 label: port7 slot: 7 type: physical - boot_disk_size: null configuration: - name: node.cfg content: |- # this is a shell script which will be sourced at boot hostname user1 # configurable user account USERNAME=cisco PASSWORD=cisco # Bring up network ip address add 192.168.11.101/24 dev eth0 ip route add default via 192.168.11.1 cpu_limit: null cpus: null data_volume: null hide_links: false id: n4 image_definition: null label: user1 node_definition: desktop parameters: {} ram: null tags: [] x: 240 y: 80 interfaces: - id: i0 label: eth0 slot: 0 type: physical - boot_disk_size: null configuration: [] cpu_limit: null cpus: null data_volume: null hide_links: false id: n5 image_definition: null label: internet-gateway node_definition: external_connector parameters: {} ram: null tags: [] x: -400 y: 119 interfaces: - id: i0 label: port slot: 0 type: physical - boot_disk_size: null configuration: [] cpu_limit: null cpus: null data_volume: null hide_links: false id: n6 image_definition: null label: ' ' node_definition: unmanaged_switch parameters: {} ram: null tags: [] x: -40 y: 120 interfaces: - id: i0 label: port0 slot: 0 type: physical - id: i1 label: port1 slot: 1 type: physical - id: i2 label: port2 slot: 2 type: physical - id: i3 label: port3 slot: 3 type: physical - id: i4 label: port4 slot: 4 type: physical - id: i5 label: port5 slot: 5 type: physical - id: i6 label: port6 slot: 6 type: physical - id: i7 label: port7 slot: 7 type: physical - boot_disk_size: null configuration: - name: node.cfg content: |- # this is a shell script which will be sourced at boot hostname guest1 # configurable user account USERNAME=cisco PASSWORD=cisco # Bring up network ip address add 10.11.15.1/20 dev eth0 ip route add default via 10.11.0.1 cpu_limit: null cpus: null data_volume: null hide_links: false id: n7 image_definition: null label: guest1 node_definition: desktop parameters: {} ram: null tags: [] x: 240 y: 160 interfaces: - id: i0 label: eth0 slot: 0 type: physical links: - id: l0 n1: n5 n2: n3 i1: i0 i2: i0 conditioning: {} label: Internet-port<->int-sw-port0 - id: l1 n1: n0 n2: n3 i1: i1 i2: i1 conditioning: {} label: cr-rtr1-Ethernet0/0<->int-sw-port1 - id: l2 n1: n1 n2: n3 i1: i1 i2: i2 conditioning: {} label: cr-rt2-Ethernet0/0<->int-sw-port2 - id: l3 n1: n0 n2: n1 i1: i2 i2: i2 conditioning: {} label: cr-rtr1-Ethernet0/1<->cr-rt2-Ethernet0/1 - id: l4 n1: n1 n2: n6 i1: i3 i2: i1 conditioning: {} label: cr-rt2-Ethernet0/2<->cr-sw-port1 - id: l5 n1: n6 n2: n2 i1: i2 i2: i1 conditioning: {} label: cr-sw-port2<->bld1-sw-Ethernet0/0 - id: l6 n1: n2 n2: n4 i1: i2 i2: i0 conditioning: {} label: bld1-sw-Ethernet0/1<->user1-eth0 - id: l7 n1: n2 n2: n7 i1: i3 i2: i0 conditioning: {} label: bld1-sw-Ethernet0/2<->guest1-eth0 - id: l8 n1: n0 n2: n6 i1: i3 i2: i0 conditioning: {} label: cr-rtr1-Ethernet0/2<-> -port0 lab: description: |- Conquering OSPF: Optimize Your Network with OSPF Maximize your network's potential with our in-depth focus on OSPF. This live stream event is tailored to help you master OSPF and optimize your network through dynamic routing and effective path selection. Perfect for networking professionals aiming to deepen their expertise, you'll be provided with the skills needed to ensure your network runs at peak performance. Join us to conquer OSPF and elevate your network optimization skills. notes: |- **CCNA Exam Prep: Back to Networking Basics with Hank Preston and Patrick Gargano** # Conquering OSPF: Optimize Your Network with OSPF As networks grow, become more complex, and rate of change increases, a move to dynamic routing is often a good choice. Dynamic routing leverages routing protocols to transmit network updates between routers automatically as changes occur, allowing routers to update their routing tables with the best options to reach destinations without requiring manual intervention by network engineers. OSPF, or Open Shortest Path First, is a widely deployed standard routing protocol that scales from small "single area" networks to large global wide area networks. CCNA candidates need to be comfortable configuring and verifying single area OSPFv2 deployments. In this lab we will explore: * Configuring IOS routers to run OSPF and share network information with neighbors * Configure and verify neighbor adjacency details such as Router IDs and Timers * Designated Router/Backup Designated Router election * Sharing a default route with OSPF ## Setup and Scenario In this set of lab-based demonstrations, you are the network engineer for a growing organization tasked with updating the network to support new network needs. The network was originally deployed using static routes as it was small, but now the network has grown from a single building to a "campus", and it is time to deploy dynamic routing. You've been asked to: * Enable OSPF between the core routers and the building 1 Layer 3 switch * Ensure reliable internet access in case of a link failure to the primary router `cr-rtr1` * Ensure the core routers provide routing updates to all building switches *Be sure to **START** the lab before continuing to the demo labs.* ## Part 1: Reviewing the Current State of the Network Before we jump into configuring OSPF across the network, let's check the current status of the network and how it is operating. 1. Open a VNC connection to the desktop `user1`. Open the Internet browser and navigate to https://u.cisco.com. * You should see the Cisco U homepage. 1. Open the terminal application and `ping www.cisco.com`. * You should see pings return successfully. > If these steps fail, verify that your CML server is configured and deployed to allow Internet access for hosts through a NAT configured external connector node. > > If your server is ***not*** configured to allow this access, you can `ping 192.168.200.1` as an alternative test. This is a loopback address on `cr-rtr1`. 1. Open a VNC connection to the desktop `guest1` and repeat the tests. * **These tests should ***not*** work.*** Uh oh... something doesn't seem to be right with the network. See if you can figure out what is wrong and why the `guest1` desktop can't reach the internet.
Answer to what is wrong This is an example of one of the problems that can happen with static routing, mis-configurations and human error. If you check `cr-rtr1` for a route back to `guest1`, you will see there isn't one listed. ``` cr-rtr1#show ip route 10.11.15.1 % Subnet not in table ``` Compare that to the backup `cr-rtr2`. ``` cr-rtr2#show ip route 10.11.15.1 Routing entry for 10.11.0.0/20 Known via "static", distance 1, metric 0 Routing Descriptor Blocks: * 172.20.1.11 Route metric is 0, traffic share count is 1 ``` Check the full routing table on `cr-rtr1` and you can find the mistake. 
    cr-rtr1#show ip route | begin Gateway
    Gateway of last resort is 192.168.255.1 to network 0.0.0.0

    S*    0.0.0.0/0 [254/0] via 192.168.255.1
          10.0.0.0/21 is subnetted, 1 subnets
    S        10.11.0.0 [1/0] via 172.20.1.11
          172.16.0.0/24 is subnetted, 1 subnets
    S        172.16.11.0 [1/0] via 172.20.1.11
    .
    .
Building 1, vlan 10's network is `10.11.0.0/20`, but `cr-rtr1` has a route for `10.11.0.0/21`. If you test a `ping 10.11.0.1` from `cr-rtr1`, you'll see that the router has reachability to the `vlan 40` interface on `bld1-sw`. But because of the incorrect subnet mask on the `ip route` command, only half of the valid IPs for guests are reachable from the router. You can "fix" this issue, but replacing the static route statement on `cr-rtr1`. ``` no ip route 10.11.0.0 255.255.248.0 172.20.1.11 ip route 10.11.0.0 255.255.240.0 172.20.1.11 ``` Test Internet access from `guest1 ` again. It should now be working.
### What did we learn? While dynamic routing doesn't prevent misconfigurations, by reducing the manual management of a large number of static routes and instead allowing the routers to send routing updates directly, this does improve reliability and remove what can be difficult troubleshooting scenarios. ## Part 2: Basics of Getting OSPF Up and Running ### Minimal configuration needed to build neighbor relationships We'll start with the minimal configuration necessary for OSPF relationships to be created between the core routers and building switch. * Enable OSPF process * Add the interfaces/networks between routers to OSPF area 0 1. Start by configuring `bld1-sw`: ``` router ospf 11 network 172.20.1.0 0.0.0.255 area 0 ``` 1. And now `cr-rtr1`: ``` router ospf 1 network 172.20.1.0 0.0.0.255 area 0 ``` 1. Some things to take note of: * Each router has a "process id". This value is locally significant on each router and does ***not*** need to match. * `network` statements with "wildcard masks" are used to match interfaces on the router to enable for OSPF 1. Watch the console output on `cr-rtr1`. After some time you should see a message like the one below. This is an indication that OSPF has completed establishing the neighbor relationship between `bld1-sw` and `cr-rtr1` and is now exchanging routing information. ``` *Oct 18 06:04:22.574: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.199.1 on Ethernet0/2 from LOADING to FULL, Loading Done ``` 1. There are many `show` commands available for OSPF, but we'll start with `show ip ospf neighbor` to view the current neighbors on `cr-rtr1`. ``` cr-rtr1# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 192.168.199.1 1 FULL/BDR 00:00:37 172.20.1.11 Ethernet0/2 ``` * The `Neighbor ID` is also called the "router ID", and represents the routers identity included in OSPF updates * `Pri` or "Priority" is used in "Designated Router" elections. Higher priority is better and values range from 0 -> 255 * `FULL/BDR` indicates that our router has completed sharing routing information (or link state database information) with this neighbor (full), and that this neighbor is the "Backup Designated Router" on this link. * The `Dead Time` is a countdown clock for when this neighbor will be considered no longer valid. If it reaches `0`, the neighbor will be removed. * `Address` indicates the next hop address to the neighbor out of the `Interface` > We'll be talking more about the Designated Router / Backup Designated Router (DR/BDR) election in the next step. 1. Another very useful command is `show ip ospf interface brief`. ``` cr-rtr1# show ip ospf interface brief Interface PID Area IP Address/Mask Cost State Nbrs F/C Et0/2 1 0 172.20.1.1/24 10 DR 1/1 ``` * This command lists all interfaces on a router that are participating in OSPF. This can be helpful when troubleshooting to ensure that the interfaces you expect to have neighbors, are actually configured for OSPF. * The "non-brief" version of the command has even more information that can be helpful for troubleshooting. 1. Run these commands on `bld1-sw` and compare the results. 1. Go ahead and configure `cr-rtr2`: ``` router ospf 2 network 172.20.1.0 0.0.0.255 area 0 ``` 1. Very quickly you should see messages on the `cr-rtr2` console that neighbor relationships with the other two routers have been established. ``` *Oct 18 06:26:52.796: %OSPF-5-ADJCHG: Process 2, Nbr 192.168.199.1 on Ethernet0/2 from LOADING to FULL, Loading Done *Oct 18 06:26:52.796: %OSPF-5-ADJCHG: Process 2, Nbr 192.168.200.1 on Ethernet0/2 from LOADING to FULL, Loading Done ``` > This was so much faster than the initial relationship between `cr-rtr1` and `bld1-sw` because the designated router election process was already complete on the "broadcast" network connecting the three routers. 1. Run the `show ip ospf neighbor` and `show ip ospf interface brief` commands on all three devices. * Each device should now have 2 neighbors * `cr-rtr2` should be in a state of `FULL/DROTHER` for the other routers ### Exploring Designated Router election and status Every interface running OSPF has a "network type" that impacts some of the details with how OSPF runs and operates. Ethernet interfaces have a type of "broadcast". Broadcast networks can have many different OSPF speaking routers on a single network segment. If every router exchanged links state databases with every other router on a broadcast network, this would result in a large amount of duplicate traffic. To be more efficient, OSPF elects a "Designated Router" (DR) to collect routing information from all other routers on the segment, and distribute ***ALL*** information to every other router. And because we like redundancy in networking, a "Backup Designated Router" (BDR) is also identified. The BDR also distributes routing information to other routers. If the DR fails, the BDR will take over immediately, and a new BDR will be elected. Like with spanning-tree, explicitly identifying the DR/BDR in an network is advised. "Core" or "hub" routers are the best candidates for this role, with "stub" routers often configured to *never* become a DR/BDR. The OSPF priority value configured on an interface determines the outcome of a DR/BDR election. The higher the priority, the more likely it will become the DR/BDR. A priority of `0` will prevent a router from participating in the election. Now we will update the configuration in our network to use the core routers for DR/BDR, and prevent the building switches (layer 3 switches) from becoming a DR or BDR. > Note: DR/BDR status on a network does NOT preempt. This means that if a new router with a higher priority comes onto a network segment with a DR already elected, the new router will NOT become the DR. If the current DR or BDR fails, this new router will then take over the role of BDR. 1. Start by using the `show ip ospf neighbor` command on each router to verify the current priority and DR/BDR roles for each router. 1. On `cr-rtr1`, increase the ospf priority of interface `Ethernet0/2` to 10. ``` interface ethernet0/2 ip ospf priority 10 ``` * You can verify the change with the `show ip ospf interface eth0/2` command 1. Access the console on `bld1-sw` and run the `show ip ospf neighbor` command. You should now see the increased priority for `cr-rtr1`. ``` Neighbor ID Pri State Dead Time Address Interface 192.168.200.1 10 FULL/DR 00:00:32 172.20.1.1 Ethernet0/0 192.168.255.64 1 FULL/DROTHER 00:00:36 172.20.1.2 Ethernet0/0 ``` 1. Now configure a priority of `0` on `bld1-sw` interface `ethernet0/0` to remove it from the `DR/BDR` election process. ``` interface ethernet0/0 ip ospf priority 0 ``` 1. Check the OSPF neighbor status on the switch again. ``` Neighbor ID Pri State Dead Time Address Interface 192.168.200.1 10 FULL/DR 00:00:38 172.20.1.1 Ethernet0/0 192.168.255.64 1 FULL/BDR 00:00:35 172.20.1.2 Ethernet0/0 ``` * Now `cr-rtr2` is the BDR for the network segment. 1. Verify that `bld1-sw` does NOT become a DR/BDR no matter what by saving the running configuration (`write mem`) on `cr-rtr2` and then **STOPPING** the router. > Only **STOP** the **router**. Do not wipe it, or stop the entire lab. 1. Wait 40 seconds for the dead timer to expire, and check the neighbor status on `cr-rtr1`. ``` *Oct 18 07:00:55.340: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.255.64 on Ethernet0/2 from FULL to DOWN, Neighbor Down: Dead timer expired cr-rtr1#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 192.168.199.1 0 FULL/DROTHER 00:00:31 172.20.1.11 Ethernet0/2 ``` > Even though there isn't another router to be the BDR on the network segment, `bld1-sw` stays in `DROTHER` state. 1. **START** `cr-rtr2`. Shortly after coming online, it should regain the `BDR` state. ### Configuring Router (Neighbor) IDs Every OSPF router needs to have a unique router ID assigned. If one is not explicitly configured, the router will chose the IP address of one of its interfaces to act as the router ID. The highest IP address assigned to a loopback address will be chosen. If no loopbacks are configured, the highest IP address on a non-loopback active interface will be selected. 
    Neighbor ID     Pri   State           Dead Time   Address         Interface
    172.20.1.2        1   FULL/BDR        00:00:32    172.20.1.2      Ethernet0/2
    192.168.199.1     0   FULL/DROTHER    00:00:33    172.20.1.11     Ethernet0/2
    192.168.200.1    10   FULL/DR         00:00:30    172.20.1.1      Ethernet0/2
> Above in red we see the automatically assigned router IDs. Can you tell which router is which? Relying on automatic router ID assignment is not recommended, because as interface configurations on routers change, the router ID will also change. While this won't prevent OSPF from working, it can make operating and troubleshooting the network more difficult as router id values adjust. Router IDs "look like" IP addresses, but they needn't be an IP address on a router. Any IP address can be used. We will configure some easy to see and identify router IDs for our network. | Router | Router Id | | ------ | --------- | | `cr-rtr1` | `1.1.1.1` | | `cr-rtr2` | `2.2.2.2` | | `bld1-sw` | `11.11.11.11` | 1. Open the console for `cr-rtr1` and configure the router ID under the `router ospf` process. ``` router ospf 1 router-id 1.1.1.1 ``` 1. You should see a message like the one shown below. To improve stability, routers identify their router ID when the OSPF process starts up and maintain that same ID, no matter configuration changes, until the OSPF process restarts. This can occur when the router reloads, or a `clear ip ospf process` command is ran. ``` % OSPF: Reload or use "clear ip ospf process" command, for this to take effect ``` 1. Another very useful verification command is `show ip protocols`. This command provides information on all routing protocols running on a router. Use it to verify the router-id on `cr-rtr1`. Notice that it still shows the automatically identified router ID value. 
        show ip protocols | begin ospf

        ! Output
        Routing Protocol is "ospf 1"
        .
        Router ID 192.168.200.1
Number of areas in this router is 1. 1 normal 0 stub 0 nssa Maximum path: 4 Routing for Networks: 172.20.1.0 0.0.0.255 area 0 . 1. Now restart OSPF on the router to apply the change. You will be asked to confirm because this will be a disruptive change on the network. ``` clear ip ospf process ``` 1. Verify that the router ID has changed. ``` show ip protocols | inc ID # Output Router ID 1.1.1.1 ``` 1. Repeat the process on `cr-rtr2` and `bld1-sw` to set their router IDs and reset the OSPF process to apply the change. > Note 💡: The OSPF process ID configured on each router is unique. `cr-rtr2` is `router ospf 2` and `bld1-sw` is `router ospf 11` 1. On `bld1-sw` look at the OSPF neighbors and see the new, more easily recognozied Router IDs. ``` bld1-sw# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 1.1.1.1 10 FULL/DR 00:00:38 172.20.1.1 Ethernet0/0 2.2.2.2 1 FULL/BDR 00:00:36 172.20.1.2 Ethernet0/0 ``` ### Advertising Dynamic Routes Now that we have the OSPF neighbor relationships created between our three routers, the time has come to replace the static routes with dynamic routes managed by OSPF. 1. Start with the Building 1 networks. On the console for `bld1-sw`, look at the IP interfaces configured. ``` show ip int bri | exc unassigned ``` 1. Compare the networks with the static routes on `cr-rtr1`. ``` show ip route static ``` 1. Other than the network on `bld1-sw` interface `Ethernet0/0` which is the transit network to the routers, each of the networks on the switch should have associated static routes. > The routers also each have a static default route. `cr-rtr1`'s static route was learned through DHCP and targets the `internet-gateway`. `cr-rtr2`'s static route was manually configured to route through `cr-rtr1` over the direct transit link. 1. OSPF is a "link state" routing protocol, which means decisions are made by exchanging details about the "links" each router has. Look at the links advertised by `bld1-sw` into OSPF. > This command can be ran on any router. ``` show ip ospf database router adv-router 11.11.11.11 ``` > * There are several different types of "LSAs" used by OSPF to describe different types of networks. The `router` LSAs are used to describe all directly connected networks > * This command is limiting the output only to LSA data advertised by `bld1-sw` - as identified by its router ID. 1. How many links are advertised by the switch? Which links? 1. Add a `network` statement under the OSPF router process configuration on `bld1-sw` to begin advertising the Vlan 10 interface for users into area 0. Remember that OSPF uses wildcard masks for matching interfaces identified in network statements. ``` router ospf 11 network 192.168.11.0 0.0.0.255 area 0 ``` 1. Look at the Link State Database again, do you see the new network listed? How is this "link" different than the other "link"? 1. Now that the "user" network is included in OSPF, check the OSPF routes in the routing table on `cr-rtr1`. ``` show ip route ospf ``` * Is the route listed? Why not?
Answer: The static routes configured on the router have a lower administrative distance than the OSPF learned routes, making them more trusted/preferred.
1. Remove the static route on both `cr-rtr1` and `cr-rtr2` for the "user" network. ``` no ip route 192.168.11.0 255.255.255.0 172.20.1.11 ``` 1. Check the OSPF routes again. Is it there? 1. `network` statements aren't the only way to add interfaces and networks into OSPF, there is also an interface configuration command that can be used. Use it to advertise the `iot` network on `bld1-sw`. ``` interface vlan 20 ip ospf 11 area 0 ``` > It is important to use the correct OSPF process number in this command. 1. Complete the configuration to ensure that the network `192.168.199.0/24` is listed as an "OSPF" route on both core routers. 1. Use either `network` statements or the interface configuration method to advertise the "security" and "guest" networks with OSPF. Be sure that they are listed as "OSPF" routes in the routing tables for the core routers. 1. Verify the routing table on `cr-rtr1` and `cr-rtr2` to confirm that you now have four OSPF entries, one for each of the VLANs in Building 1. 1. Verify that both desktops can still access the Internet. Either by browsing to https://u.cisco.com using a VNC connection, or by pinging `8.8.8.8`. ## Part 3: Further OSPF Exploration with Enhancements, Troubleshooting, and Tuning You've now completed the basic setup of OSPF on this network, moving from static routing to dynamic routing. But that isn't the end of the OSPF journey. In this part, you will explore a few more aspects of OSPF. ### Troubleshooting OSPF Neighbor Relationships Look at the network topology. Notice the direct link between the two core routers? This transit network provides an alternative path between the routers should either router lose its link to the "Core Routing" network segment shared with `bld1-sw`. In this step, we will extend OSPF area 0 to include this link. 1. From the console connection of `cr-rtr1`, use the interface configuration command to add `Ethernet0/1` to ospf area 0. ``` interface eth0/1 ip ospf 1 area 0 ``` 1. Repeat on `cr-rtr2`, using OSPF process 2. 1. The DR/BDR election takes 40 seconds (the equivalent of the "dead timer") to complete. Wait that time and check the status of the neighbor relationship on both routers using the following commands: ``` show ip ospf neighbor show ip ospf interface brief ``` * Which routers is the designated router for the link? * Did the routers form a neighbor relationship? * What is wrong?
Answer Notice that both routers elected themselves designated router for the network segment. Only one DR should be present on this link. In order for two routers to become OSPF neighbors, several configuration parameters must match on the devices. These include: The two routers do NOT have the same network details. `cr-rtr1` is configured with a /30 mask, while `cr-rtr2` uses a /24 mask. This difference prevents the routers from becoming neighbors. As far as each router is concerned, they are part of different OSPF networks on this link.
1. The link between the two routers is a direct connection between two routers. There will only ever be 2 hosts on this link, so a `/30` subnet is correct. Change the configuration on `cr-rtr2` for `interface eth0/1` to use the same IP address but the correct subnet mask. * You should quickly see the below message indicating that the neighbor relationship was established. Use the OSPF `show` commands to verify the current status is as expected. ``` *Oct 28 06:27:50.762: %OSPF-5-ADJCHG: Process 2, Nbr 1.1.1.1 on Ethernet0/1 from LOADING to FULL, Loading Done ``` ### Advertising a Default Route Dynamically Currently a static route is used on `bld1-sw` to send Internet traffic through `cr-rtr1` as the primary path, with a floating static route configured to use `cr-rtr2` as an alternative. ``` bld1-sw# show run | section ip route ip route 0.0.0.0 0.0.0.0 172.20.1.1 ip route 0.0.0.0 0.0.0.0 172.20.1.2 10 ``` #### Testing the floating static default route 1. Test that this is working by starting a ping from the `user1` desktop to the Internet with the command `ping 8.8.8.8`. 1. Once it is running, `shutdown` interface `Ethernet0/2` on `cr-rtr1`. This will break the path to the internet from `bld1-sw`. > `Ethernet0/2` is the interface that connects to the transit network between the devices. 1. What happens to the ping from the desktop? 1. Did the floating static route work? Why not?
Answer bld1-sw won't use the floating static route unless the primary route is considered "unreachable". A broken link from the router to the "transit switch" doesn't impact bld1-sw connection the the directly connected network used to reach the next-hop 172.20.1.1. Furthermore, anything that did make cr-rtr1's address unreachable, would also impact cr-rtr2 - they are on the same network / subnet. This shows how simple floating static routes are not sufficient in many cases. And why dynamic routing is preferred.
1. Re-enable the interface on `cr-rtr1` and verify that the ping resumes working. #### Advertise a default route from `cr-rtr1` into OSPF A default network is added to OSPF with the special command `default-information originate`. 1. Add this command to the `router ospf` process configuration on `cr-rtr1`. ``` router ospf 1 default-information originate ``` 1. Default routes are considered "external networks" within OSPF. Check for an "external LSA" on any router. ``` show ip ospf database external ``` 1. We already have seen that static routes will be preferred over OSPF routes, remove both static default routes from `bld1-sw`. ``` no ip route 0.0.0.0 0.0.0.0 172.20.1.2 10 no ip route 0.0.0.0 0.0.0.0 172.20.1.1 ``` 1. Check the default route on `bld1-sw` now. ``` show ip route show ip route 0.0.0.0 ``` > The second command provides some additional route details, including the "type" of OSPF route it is. The "External type 2" matches the LSA database output we saw. #### Testing Dynamic Default Routing With the changes made, test that `bld1-sw` can maintain a valid path to the Internet even if the link to `cr-rtr1` fails. 1. Test that the primary path is working by tracing the first four hops in the path to `8.8.8.8` on `user1`. ``` traceroute -m 4 -n 8.8.8.8 # Output 1 192.168.11.1 0.940 ms 0.816 ms 0.738 ms 2 172.20.1.1 1.556 ms 1.173 ms 1.294 ms 3 192.168.255.1 1.593 ms 1.754 ms 1.583 ms 4 10.1.1.1 1.916 ms 1.722 ms 2.042 ms ``` > Hop 2, `172.20.1.1` is `cr-rtr1` as expected. 1. Start a ping from the `user1` desktop to the Internet with the command `ping 8.8.8.8`. Let it run to look for impact of an outage. 1. Once it is running, `shutdown` interface `Ethernet0/2` on `cr-rtr1`. This will break the path to the internet from `bld1-sw`. > `Ethernet0/2` is the interface that connects to the transit network between the devices. 1. What happens to the ping from the desktop? * No pings should be lost, or possibly 1 or 2 ping packets, because OSPF updates the interface state before IOS actually takes the interface down. 1. Stop the ping on `user1`, and repeat the `traceroute`. ``` traceroute -m 4 -n 8.8.8.8 traceroute to 8.8.8.8 (8.8.8.8), 4 hops max, 46 byte packets 1 192.168.11.1 1.085 ms 0.618 ms 0.701 ms 2 172.20.1.2 1.956 ms 1.494 ms 1.183 ms 3 172.20.0.1 2.472 ms 2.116 ms 1.793 ms 4 192.168.255.1 2.517 ms 2.358 ms 2.448 ms ``` > Hop 2 is now `172.20.1.2`, or `cr-rtr2`. At hop 3, `172.20.0.1`, traffic goes across the transit link to `cr-rtr1` to reach the Internet. 1. Re-enable the interface on `cr-rtr1` and verify the path returns to directly through `cr-rtr1`. #### Configuring the Backup Default Gateway `cr-rtr2` is configured to prefer the a path to the internet through `cr-rtr2` over the direct link it has to the `internet-gateway`. But if `cr-rtr1` goes down completely, it needs to provide an alternative path to the Internet. If multiple `default-information originate` routers are configured on a network, the `metric` can be used to perfer one path over another. > Note 💡: `cr-rtr2` is configured with IP SLA tracking as part of the static route through `cr-rtr1`. IP SLA tracking is out of scope for the CCNA, but feel free to look at the configuration and research the topic on your own. 1. Configure `cr-rtr2` to originate a default route with a metric of `10000`. ``` router ospf 2 default-information originate metric 10000 ``` 1. Use `show ip ospf database external` to see the new LSA from `cr-rtr2`. How does it differ from the external LSA from `cr-rtr1`? Why does the `Forward Address` point to `cr-rtr1`? 1. Start a ping to `8.8.8.8` from `user1` to test for outage impact. 1. Save the running configuraiton on `cr-rtr1` so none of your changes are lost. ``` copy running-config startup-config ``` 1. **Stop** but do ***NOT*** *Wipe* `cr-rtr1`. 1. Monitor the ping and syslog messages on the routers. 1. Once the pings being working again, check the routing table on `bld1-sw`. * What is the default gateway now? * What is the metric of the default route now? 1. **Start** `cr-rtr1`. * Once it restarts, verify the default route on `bld1-sw` has returned to the path through `cr-rtr1`. ### Speeding up failure detection Routers do not always have a chance to send out updates when a failure happens. In these cases, the OSPF timers configured on the network are used to remove invalid routes. #### Testing Recovery Time When a Cable Breaks 1. Start a ping from the `user1` desktop to the Internet with the command `ping 8.8.8.8`. Let it run to look for impact of an outage. 1. Open the console for `bld1-sw` and run the command `show clock` to display the current time on the switch. 1. Find and click the link from `cr-rtr1` to the switch that connects to `cr-rtr2` and `bld1-sw` and choose "Delete". 1. Wait and monitor the console output on the `bld1-sw` and the results of the ping. Once the pings begin responding again, press `Cntrl-C` to stop the ping and answer these questions. * How many pings were lost? * Use the timestamp from the `show clock` command, and the syslog message about `%OSPF-5-ADJCHG: ... FULL to DOWN, Neighbor Down: Dead timer expired` to calculate how long it took for the network to respond to the outage * Why?
Answer: It should be about 40 ping packets lost, and about 40 seconds of time before the switch marks the router as "dead". The reason for this is the default OSPF "dead timer" is 40 seconds, or specifically a default of 4 times the hello time. If a neighbor doesn't check in within the "dead time", then it will be flushed from the OSPF database, along with all routes in the routing table related to that neighbor.
1. Replace the deleted link from `cr-rtr1` to the switch. Use interface `Ethernet 0/2` on the router and any port on the switch. #### Configuring a Faster Neighbor Outage Detection The two timers in OSPF for neighbor relationships are the "hello interval" timer and the "dead interval" timer. The hello interval is how often a hello packet is sent between routers to build and maintain neighbor relationships. The dead interval is how long a router will wait for a hello packet on a link before marking a neighbor as "dead". The defaults on Cisco IOS are 10 second hello interval and 40 second dead interval (the default dead interval is 4 times the hello interval). These defaults are pretty good and work for many networks, but sometimes you want to detect and recover from failures faster. You can do this by reducing the intervals on specific interfaces. IP networks by design are not 100% reliable, so using a 4x hello interval for the dead interval is a good practice. And always remember you are balancing faster response time with extra overhead on the network. *Also important to remember, the OSPF timers are one of the factors that must match in order for neighbor relationships to be built and maintained. So changing timers are disruptive to the network.* 1. On `bld1-sw` interface `Ethernet 0/0` change the timers to 1 second hello, and 4 second dead. ``` interface eth0/0 ip ospf hello-interval 1 ip ospf dead-interval 4 ``` 1. If you wait 40 seconds, you'll see messages about the neighbor relationships with the other routers going down. Why is this? 1. Change the timers on `cr-rtr1` and `cr-rtr2` interfaces `Ethernet 0/2` to match. #### Testing the new recovery time Repeat the test cable break. Use the same process and answer these questions: * How many pings were lost? * Use the timestamp from the `show clock` command, and the syslog message about `%OSPF-5-ADJCHG: ... FULL to DOWN, Neighbor Down: Dead timer expired` to calculate how long it took for the network to respond to the outage * Why?
Answer: It should be about 4 ping packets lost, and close to 4 seconds of time before the switch marks the router as "dead".
Much faster! title: CCNA Prep 2024 S1E5 Conquering OSPF version: 0.2.2