OSPF Single-Area Networks
Module Introduction
Before you start the hands-on part of this module, you should load the appropriate configuration and verify that the testbed is up and running by executing the corresponding robot file:
student@tour:~/trainings_resources/robot$ robot ospf_single_area/ospf_single_area_setup.robot
In order to get a better understanding, the lab setup is shown in the picture below.
OSPF Overview
Open Shortest Path First (OSPF) is a link-state routing protocol designed to find the best path within an IP network. The term open is used to indicate that the Dijkstra Shortest Path First (SPF) algorithm, which is used to construct the topology and routing table, is not proprietary to any vendor. OSPF is used within an autonomous system and is thus classified as an interior gateway protocol (IGP). It has proven to be a very scalable routing protocols, supporting tens of thousends of nodes.
Since its original IETF specification, OSPF has evolved and been enhanced through several RFCs. Currently, there are two versions in use: version 2, defined in RFC 2328 for IPv4 networks, and version 3 for IPv6 networks, defined in RFC 5340.
As of software version 23.8.1, RBFS only supports IPv4 networks. |
OSPF uses five different packet types to establish and maintain OSPF neighborship and exchange routing information:
-
Hello packets
-
Database Description packets
-
Link State Request packets
-
Link State Update packets
-
Link State Acknowledgment packets
OSPF Neighbors
Establishing OSPF Neighborship
OSPF routers establish neighborships with each other to exchange routing information, ensuring the consistency and accuracy of their link-state databases. OSPF routers use a Hello protocol to discover OSPF neighbors and establish adjacencies with them. The Hello protocol involves the exchange of Hello packets over OSPF-enabled interfaces. Routers periodically send Hello packets to monitor the status of existing neighbors.
Hello packets contain various essential pieces of information, including:
-
OSPF Router ID of the originating router
-
OSPF area ID
-
Subnet mask of the interface on which the Hello packet is sent
-
OSPF network type
-
Hello and Dead timers
-
Authentication type and authentication key
-
Router priority
-
Designated router (DR) and backup designated router (BDR)
-
a list of recognized OSPF neighbors on the particular interface
When two routers on a network send and receive Hello packets, they first check whether the information in the Hello packets received matches specific criteria, i.e., the attributes marked in the list above must match.
OSPF supports five different network types, with the most important ones being point-to-point (p2p) and broadcast. In broadcast networks, such as Ethernet, Hello packets are sent to the All OSPF Routers multicast address (224.0.0.5), and a designated router (DR) and backup designated router (BDR) are elected. Once the DR and BDR are elected, all other OSPF routers will form an OSPF neighborship only with the DR and BDR and will send routing updates to a multicast address dedicated to DR and BDR only (224.0.0.6). Point-to-point networks were originally developed for PPP and Frame Relay but are also used in modern networks for high-speed Ethernet interfaces. The advantage of using the p2p mode is that no DR and BDR are elected. |
Once the Hello packet checks are successful, the routers go through a series of state transitions:
-
Down state is the initial state before neighbors are discovered, indicating that no Hello packets were received within the dead time interval.
-
Init state indicates that a Hello packet has been received, and the process to establish a neighbor relationship has begun.
-
2-way state indicates that a router has identified its own router ID in the neighbor list of the Hello packet received from the peer. At this point, the negotiation of the Designated Router (DR) and Backup Designated Router (BDR) takes place if necessary.
-
Exstart state is used to prepare for the exchange of database description packets by negotiating the initial sequence numbers for link-state advertisements.
-
Exchange state is used to exchange database description packets that provide information about the entire link-state database.
-
Loading state indicates that specific missing link-state advertisements are requested because they are absent from the link-state database.
-
Full state represents OSPF neighbors that have successfully synchronized their Link-State Databases.
If a router does not receive Hello packets from its neighbor within the configured Dead timer interval, it assumes the neighbor is no longer reachable, and the neighbor relationship is torn down again.
Configuring OSPF Neighbors
Now that we have understand the basic concept of OSPF Hello protocol, let’s configure the OSPF neighbors using the set instance <instance> protocol ospf address-family ipv4 area <area-id>
syntax.
Configure OSPF protocol in instance default with area 0.0.0.0 and include the interfaces hostif-0/0/1/0, hostif-0/0/2/0 and lo-0/0/0/0 in the configuration. Set the network-type of the interfaces to point-to-point.
How many OSPF neighbors can you see?
Click to reveal the answer
cfg> set instance default protocol ospf address-family ipv4 router-id 192.168.0.1
cfg> set instance default protocol ospf address-family ipv4 area 0.0.0.0 interface hostif-0/0/1/0
cfg> set instance default protocol ospf address-family ipv4 area 0.0.0.0 interface hostif-0/0/1/0 network-type p2p
cfg> set instance default protocol ospf address-family ipv4 area 0.0.0.0 interface hostif-0/0/2/0
cfg> set instance default protocol ospf address-family ipv4 area 0.0.0.0 interface hostif-0/0/2/0 network-type p2p
cfg> set instance default protocol ospf address-family ipv4 area 0.0.0.0 interface lo-0/0/0/0
cfg> commit
cfg> show ospf neighbor
cfg> show ospf interface
Instance: default
Interface Area IP Address State Type Cost Priority DR BDR MTU
hostif-0/0/1/0 0.0.0.0 172.16.0.1 P2P p2p 10000 1 0.0.0.0 0.0.0.0 1500
hostif-0/0/2/0 0.0.0.0 172.16.0.5 P2P p2p 10000 1 0.0.0.0 0.0.0.0 1500
lo-0/0/0/0 0.0.0.0 192.168.0.1 P2P p2p 10000 1 0.0.0.0 0.0.0.0 1500
Although the configuration seems to be right, there is no OSPF neighborship established.
The command show ospf neighbor
provides a list of all detected neighbors:
cfg> show ospf neighbor
You should not see any OSPF neighbors at all. But what’s the problem? Assuming everything is configured correctly, let’s check whether the remote switch is sending any useful packets or not:
cfg> show ospf interface hostif-0/0/1/0
Instance: default
Interface Area IP Address State Type Cost Priority DR BDR MTU
hostif-0/0/1/0 0.0.0.0 172.16.0.1 P2P p2p 10000 1 0.0.0.0 0.0.0.0 1500
cfg> show ospf interface hostif-0/0/1/0 detail
Instance: default
Interface: hostif-0/0/1/0, Area: 0.0.0.0
State: P2P, Type: p2p, Primary IPv4: 172.16.0.1, Router priority: 1
Designated router: 0.0.0.0, Backup designated router: 0.0.0.0
Hello interval: 10, Router dead interval: 40, Wait timer: 40
Metric: 10000, IPv4 MTU: 1500, Auth type: none
Capabilities: *|-|-|-|-|-|E|*
Received messages:
Hello: 0, Data descriptor: 0, LS request: 0 (1)
LS update: 0, LS acknowledgement: 0
Sent messages:
Hello: 11, Data descriptor: 0, LS request: 0 (2)
LS update: 0, LS acknowledgement: 0
1 | The local device does not receive any OSPF Hello messages. |
2 | The local router sends OSPF Hello packets. |
Let’s turn on packet capture on this interface and see if there is any packet incoming:
cfg> capture interface hostif-0/0/1/0 direction both
Success : ifl capture started
<...>
2023-10-17T05:12:27.014077+0000 7a:77:1f:c0:00:01 > 01:00:5e:00:00:05, ethertype IPv4 (0x0800), length 78: (tos 0xc0, ttl 1, id 28, offset 0, flags [none], proto OSPF (89), length 64)
172.16.0.1 > 224.0.0.5: OSPFv2, Hello, length 44
Router-ID 192.168.0.1, Backbone Area, Authentication Type: none (0) (1)
Options [External]
Hello Timer 10s, Dead Timer 40s, Mask 255.255.255.252, Priority 1
Designated Router 172.16.0.1
2023-10-17T05:12:32.046463+0000 7a:fc:da:c0:00:01 > 01:00:5e:00:00:05, ethertype IPv4 (0x0800), length 94: (tos 0xc0, ttl 1, id 109, offset 0, flags [none], proto OSPF (89), length 80)
172.16.0.2 > 224.0.0.5: OSPFv2, Hello, length 44
Router-ID 192.168.0.2, Backbone Area, Authentication Type: MD5 (2) (2)
Key-ID: 1, Auth-Length: 16, Crypto Sequence Number: 0x652e17c0
Options [External]
Hello Timer 10s, Dead Timer 40s, Mask 255.255.255.252, Priority 1
<...>
1 | Outgoing Hello packets do not use authentication. |
2 | Incoming Hello packets use the authentication type MD5. |
As we can see from the output above, the remote OSPF router uses MD5 authentication to encrypt the hello messages. This is the reason why no Hello packets appear in the interface statistics and thus no OSPF neighborship is established.
In order to enable OSPF authentication in RBFS, you need to create an authentication-profile
at the global configuration level, which contains the authentciation-type and password. This profile can be attached either at
-
the area-level using the command
set instance <instance> protocol ospf address-family ipv4 area <area> authentication-profile <profile>
in case all interfaces share the same authentication key, or -
the interface-level using the command
set instance <instance> protocol ospf address-family ipv4 area <area> interface <iflname> authentication-profile <profile>
if different authentication settings are used on different interfaces.
Configure OSPF authentication for interface hostif-0/0/1/0 and hostif-0/0/2/0 using type md5 and password rtbrick. The key-id should be set to 1. Can you see any OSPF neighbors now?
Click to reveal the answer
cfg> set authentication-profile MYOSPFAUTH key 1 type md5
cfg> set authentication-profile MYOSPFAUTH key 1 plain-text rtbrick
cfg> set instance default protocol ospf address-family ipv4 area 0.0.0.0 authentication-profile MYOSPFAUTH
cfg> commit
cfg> show ospf neighbor
Instance: default
Address Interface Router ID Area State Priority DR BDR Uptime Expires
172.16.0.2 hostif-0/0/1/0 192.168.0.2 0.0.0.0 Full 1 0.0.0.0 0.0.0.0 0d:00h:01m:16s 40 Seconds
172.16.0.6 hostif-0/0/2/0 192.168.0.3 0.0.0.0 Full 1 0.0.0.0 0.0.0.0 0d:00h:01m:16s 39 Seconds
OSPF Link-State Database
We have already mentioned that OSPF is a link-state routing protocol, i.e., instead of sending its view of the routing table to its neighbors, OSPF routers generate link-state advertisements (LSAs) whenever something changes. These LSAs then need to be sent to all routers in the OSPF network. This process is called flooding. As a result all OSPF routers have the same information which is stored in the link-state database and used to calculate the routing table using the SPF algorithm.
Link-state advertisments are carried within link-state update (LSU) packets which can contain multiple LSAs for sake of efficiency. The receipt of a link-state update packet is responded to with an link-state acknowledge packet. |
Router LSA
The OSPF link-state database can be examined using the show ospf database
command:
cfg> show ospf database
Instance: default, Area: 0.0.0.0
Type Link State ID Advertising Router Age Sequence Checksum Cost Link Count
Router 192.168.0.1 192.168.0.1 13 0x80000004 0x23ce - 5
Router 192.168.0.2 192.168.0.2 14 0x80000006 0xbb90 - 7
Router 192.168.0.3 192.168.0.3 14 0x80000007 0xc06f - 7
Router 192.168.0.4 192.168.0.4 1557 0x80000004 0x57b2 - 5
From the output above, we can identify four entries in the link-state database with type Router. OSPF has a couple of LSA types which we will introduce step-by-step. The most important one is the router LSA (or type-1 LSA). Every router in the OSPF area generates exactly one router LSA. The corresponding LSA ID is set to the router ID of the particular router. The router LSA contains a list of links attached to the OSPF router:
cfg> show ospf database ls-id 192.168.0.1 detail
Instance: default, Area: 0.0.0.0 LSAs
LSA ID: 192.168.0.1
Advertising router: 192.168.0.1, LSA type: Router
Sequence number: 0x80000004, Checksum: 0x23ce, LSA age: 48
Length: 84, Options: *|-|-|-|-|-|E|*, Flags: -|-|-|-
Number of links: 5
Link ID: 192.168.0.2
Link data: 172.16.0.1, Type: P2P
Type of service: 0, Metric: 10000
Link ID: 172.16.0.0
Link data: 255.255.255.252, Type: Stub
Type of service: 0, Metric: 10000
Link ID: 192.168.0.3
Link data: 172.16.0.5, Type: P2P
Type of service: 0, Metric: 10000
Link ID: 172.16.0.4
Link data: 255.255.255.252, Type: Stub
Type of service: 0, Metric: 10000
Link ID: 192.168.0.1
Link data: 255.255.255.255, Type: Stub
Type of service: 0, Metric: 10000
The content of the link-state database is used as input for the Dijkstra algorithm to calculate the shortest path from the local router to each OSPF router in the area. The Dijkstra algorithm is based on a metric called link costs and the preferred path is the one with the lowest sum of all costs of outgoing interfaces to the destination.
cfg> show ospf spf result
Instance: default, Area: 0.0.0.0
Node ID Type Cost Advertising Router Flags Neighbor Node Interface Nexthop
192.168.0.1 ROUTER 0 192.168.0.1 -|-|-|- - local -
192.168.0.2 ROUTER 10000 192.168.0.2 -|-|-|- 192.168.0.2 hostif-0/0/1/0 172.16.0.2
192.168.0.3 ROUTER 10000 192.168.0.3 -|-|-|- 192.168.0.3 hostif-0/0/2/0 172.16.0.6
192.168.0.4 ROUTER 10100 192.168.0.4 -|-|-|- 192.168.0.2 hostif-0/0/1/0 172.16.0.2
192.168.0.3 hostif-0/0/2/0 172.16.0.6
cfg> show ospf route
Instance: default, AFI: ipv4, SAFI: unicast
Prefix Area Type Cost Next Hop Interface
172.16.0.0/30 0.0.0.0 ospf-direct 10000 n/a local
172.16.0.4/30 0.0.0.0 ospf-direct 10000 n/a local
172.16.0.8/30 0.0.0.0 intra-area 10100 172.16.0.2 hostif-0/0/1/0
172.16.0.12/30 0.0.0.0 intra-area 10100 172.16.0.6 hostif-0/0/2/0
172.16.0.2 hostif-0/0/1/0
172.16.0.16/30 0.0.0.0 intra-area 10100 172.16.0.6 hostif-0/0/2/0
192.168.0.1/32 0.0.0.0 ospf-direct 10000 n/a local
192.168.0.2/32 0.0.0.0 intra-area 20000 172.16.0.2 hostif-0/0/1/0
192.168.0.3/32 0.0.0.0 intra-area 20000 172.16.0.6 hostif-0/0/2/0
192.168.0.4/32 0.0.0.0 intra-area 20100 172.16.0.6 hostif-0/0/2/0
172.16.0.2 hostif-0/0/1/0
Configuring Link Costs
By default, the metric of all OSPF interfaces in RBFS is set to 10000. Usually, you want to modify these value in order to steer traffic in your network, e.g., preferring high-speed links over low-speed links. The link metric can be modified on a per-interface basis.
Configure the link cost (metric) to be 100 for hostif-0/0/1/0 and hostif-0/0/2/0 and verify the result.
Click to reveal the answer
cfg> set instance default protocol ospf address-family ipv4 area 0.0.0.0 interface hostif-0/0/1/0 metric 100
cfg> set instance default protocol ospf address-family ipv4 area 0.0.0.0 interface hostif-0/0/2/0 metric 100
cfg> commit
cfg> show ospf spf result node-id 192.168.0.4
Instance: default, Area: 0.0.0.0
Node ID Type Cost Advertising Router Flags Neighbor Node Interface Nexthop
192.168.0.4 ROUTER 200 192.168.0.4 -|-|-|- 192.168.0.2 hostif-0/0/1/0 172.16.0.2
192.168.0.3 hostif-0/0/2/0 172.16.0.6
Redistribution and External LSAs
OSPF will advertise only link states of OSPF-enabled interfaces, by default. If you have other routing sources, e.g., direct routes or static routes, OSPF allows you to distribute this information as part of an external LSA (or type-5 LSA). A OSPF router that inject an external LSA into the OSPF network is called an Autonomous System Boundary Router (ASBR).
Configure a static route in instance default for destination 172.16.100.0/24 pointing to interface null0 and then redistribute it using the command set instance default protocol ospf address-family ipv4 redistribute static
.
Click to reveal the answer
cfg> set instance default static route ipv4 172.16.100.0/24 unicast DISCARD
cfg> set instance default static nexthop-profile DISCARD exit-interface null0
cfg> set instance default protocol ospf address-family ipv4 redistribute static
cfg> commit
Now, let’s have a look at the OSPF database again:
cfg> show ospf database
Instance: default, Area: 0.0.0.0
Type Link State ID Advertising Router Age Sequence Checksum Cost Link Count
Router 192.168.0.1 192.168.0.1 10 0x80000006 0x2b0e - 5
Router 192.168.0.2 192.168.0.2 335 0x80000006 0xbb90 - 7
Router 192.168.0.3 192.168.0.3 335 0x80000007 0xc06f - 7
Router 192.168.0.4 192.168.0.4 78 0x80000005 0x55b3 - 5
Instance: default
Type Link State ID Advertising Router Age Sequence Checksum Cost Link Count
External 172.16.100.0 192.168.0.1 5 0x80000001 0x8b3f 16777214 -
cfg> show ospf database ls-id 172.16.100.0 detail
Instance: default LSAs
LSA ID: 172.16.100.0
Advertising router: 192.168.0.1, LSA type: External
Sequence number: 0x80000001, Checksum: 0x8b3f, LSA age: 18
Length: 36, Options: *|-|-|-|-|-|-|*
Forwarding address: 0.0.0.0, Mask: 255.255.255.0, Route tag: 0
Metric: 16777214, Metric type: EXTERNAL_TYPE_1
As expected, there is a new type of LSA in the database representing the OSPF external route.
With external LSAs, there are two different metric types: type-1 metrics are similar to link metrics and the total cost is the sum of all costs along the path. On the other hand, type-2 metrics have a fixed cost value independed of the path to the ASBR. By default, RBFS uses type-1 metrics. The metric type can be set using the command |