Share this
OSPF Configuration (Pt. 2) – Misc. Features and Multi-Area Configuration
by PivIT Global on May 6, 2022 11:48:46 AM
OSPF can be implemented by using two different approaches, single-area or multi-area deployment. In a single-area design, all routers are part of the same area and are an appropriate option for small networks. Let’s not forget that in such a scenario many link-state advertisements (LSAs) will be flooded throughout the area and processed by each router.
Even though the advantage of that results in each router accumulating the same knowledge about the topology, the disadvantage outweighs it, causing larger routing tables built on each router.
On the other side, for enterprise networks, a multi-area design is a better option. By using this approach, the network is segmented into smaller domains (areas), each one working independently from the others.
This is accomplished by configuring summarization of routes between the areas on the area border routers (ABR). This results in smaller routing tables by limiting the propagation of LSAs throughout the areas.
In this article, we are going to focus on multi-area OSPF configuration and some additional features that can help in the optimization process of OSPF as well as routing in general.
To brush up on the basics and single area OSPF configurations, go here.
Want to compare interior routing protocols? Read our in-depth comparison here.
OSPF Multi-Area Configuration
Configuring OSPF in multi-area designed networks is not that different than in a single-area design. The difference is that instead of using neighbor adjacencies between the routers in the backbone area only, there is now an OSPF relationship between routers in other areas as well.
On top of that, the ABRs have neighbor adjacencies to routers in multiple areas because they are part of two or more areas (no more than 3 is recommended).
Let PivIT handle the OSPF configuration on your network with EXTEND, which serves as a seamless and confidential extension of your IT teams. Consider us your boots on the ground working to cost-effectively extend your reach and complete your projects.
The image below shows a multi-area OSPF topology with three areas, namely, Area 0 or the backbone area, and then the additional Area 1 and Area 2. We will focus only on the configuration of routers R1 (internal router in Area 1), R2 (ABR), and R3 (backbone router) because the rest of the routers will be configured in the same way.
As for the verification part, we will use other routers as well, to get a better understanding of the benefits of OSPF and its additional features.
For more details on the basics of OSPF and configuring it in a single-area on a Cisco router, see Part 1 of this two-part series.
The routers need to be configured for OSPF for the corresponding areas in which they belong. Depending on the network command, OSPF can be enabled on a single interface, multiple interfaces at the same time, or all interfaces.
Once correctly configured, verification is required so we will have confirmation that OSPF is properly operating and routers are learning networks from the other areas.
Since Area 1 contains many networks, all those should be learned by R5 (part of Area 2). For that reason, we will focus on R5 by verifying the routing table if those networks are learned, along with the networks used on the point-to-point links between the routers in the backbone area and Area 1.
If you are having trouble with the OSPF configuration, send PivIT a request or connect with our Team in real-time using our chat feature. Are you looking to configure more routers with OSPF? Click below to see how we can meet your sourcing needs!
Additional OSPF Options
Now that we know how the configuration of OSPF in multi-area design works, we can continue with some additional tuning options to optimize the overall behavior and save on some resources.
OSPF Route Summarization
By default, there is no route summarization performed on the routers when OSPF is enabled. For that reason, two major problems arise: large routing tables and frequent LSA flooding throughout the areas in the Autonomous System (AS).
As a result, each router knows every single network available. However, when something changes, such as a link failure or the network going down, it affects all the other routers in the AS, resulting in recalculations and making appropriate updates without any real benefit.
The solution is route summarization which summarizes network updates when they are exchanged between the areas. This is implemented on the ABRs, and instead of sending updates for each network, only one or more summary routes that include all separate routes will be sent to the other areas.
Thus, when something happens to some of the networks in the originating area, it will not reflect on the routers in the other areas using only the summary route containing those networks. Keep in mind that route summarization requires a good addressing plan because summarization of networks works only if they have something in common (e.g., the first two octets).
In the topology image, most of the networks are available in Area 1, so implementing route summarization on the ABR R2 will reduce the routing table size of the other routers from other areas. As a result, R5 in Area 2 should not see the internal networks of Area 1 anymore, but only a summary route.
Default Route in OSPF
Every single router needs a default route so when a route to the destination network is not available in the routing table, the packet can be is sent to the gateway of last resort and not get dropped.
One way of using default routes is to configure them on each router manually, which can be quite difficult in large enterprises. The other way is to exchange a default route dynamically between the routers through the OSPF protocol.
In the topology, R3 is the router that connects to the external AS which can be a partner network or the Internet, so the default route must be available on this router before it starts sharing itself with the rest of the routers in the OSPF domain.
To verify that other routers learn the default route through OSPF, we can check the routing table on R5 and perform a ping to 8.8.8.8 to confirm that it works.
OSPF Special Area Types
The OSPF protocol supports several area types and according to the requirements and the goal, one or another might be a better fit. By default, when configuring areas in the OSPF domain all those are of type normal.
However, additional area types can be used, such as stub area, totally stubby area, not-so-stubby area (NSSA), and totally not-so-stubby area. Even though the names sound funny and strange, these are the real names, and each area type performs differently.
The main idea behind the area types is to filter out the amount of information learned and stored on the routers. Filtering some of the LSAs exchanged results in reducing the size of the link-state database (LSDB) of the routers inside the area, as well as the memory required.
For example, instead of one router knowing every single network in the topology, changing the area type will result in learning only networks from other areas, but not external to the OSPF domain, or just a default route to reach any network outside the local area, including the external domain.
To see the benefits of the area types, we will configure Area 2 as a totally stubby area. This will filter out everything on R5 except the default route (and the local networks from Area 2), that will be used to reach any other network in the OSPF domain or the external domain. Therefore, both routers R4 and R5 should be configured properly, defining Area 2 as a totally stubby area.
OSPF Configuration Summary
To summarize, the OSPF protocol has been on the market for a very long time and is the most used protocol in the networks today. Besides its simplicity, it offers many additional tuning features that can optimize the performance as well as the overall routing process.
Additionally, authentication can be used as a protection from undesired OSPF links between the routers. For more information about OSPF authentication and why it is so important, look at our article entitled An Engineer's Guide to Configuring OSPF Authentication.
Share this
- Configuration Guides (47)
- Cisco Routers (29)
- Switches (27)
- Network Security (23)
- Cisco Switches (21)
- Routing Protocols (21)
- Routers (20)
- Cisco (19)
- Product Comparisons (19)
- Firewall (18)
- Cisco Security (17)
- Cisco Technical Information (17)
- IT Hardware Solutions (17)
- Network Protocols (17)
- Wireless (17)
- Security (15)
- OneCall (13)
- Servers (12)
- cisco asa (12)
- Cisco Wireless (11)
- Router Protocols (11)
- Cisco Catalyst (9)
- Cisco UCS (9)
- Upgrading Network (9)
- Cisco Servers (8)
- Product Highlight (8)
- Access Control Lists (7)
- Fortinet (7)
- Server Comparisons (7)
- Access Points (6)
- Arista Networks (6)
- OSPF (6)
- Wireless APs (6)
- Cisco ASR (5)
- Cloud Solutions (5)
- HPE-Aruba Wireless (5)
- Juniper Mist (5)
- Network Management (5)
- SD-WAN (5)
- Storage (5)
- Switch Comparison (5)
- Back To Basics (4)
- Cybersecurity (4)
- EIGRP (4)
- Firewall Architecture (4)
- HSRP (4)
- Juniper Networks (4)
- Network Automation (4)
- Network Servers (4)
- OEM Comparison (4)
- Aruba Central (3)
- Cisco Telephony (3)
- DHCP (3)
- DHCP Snooping (3)
- Dell EMC PowerEdge (3)
- Internet (3)
- Maintenance (3)
- Maintenance Renewal (3)
- Network Accessories (3)
- TPM (3)
- Telephony (3)
- aruba (3)
- Cisco NX-OS (2)
- Cisco Nexus (2)
- Dell Servers (2)
- Fortinet NGFWs (2)
- IT Trends (2)
- LAN Networks (2)
- Network Time Protocol (2)
- Palo Alto NGFWs (2)
- Rapid PVST+ (2)
- Remote Configuration (2)
- Software Defined Networking (2)
- WLAN (2)
- Ways to Save (2)
- fortigate (2)
- Asset Management (1)
- CPU Usage (1)
- Cisco AIR-CT (1)
- Cisco Aironet (1)
- Cisco DNA (1)
- Cisco ISR (1)
- Cisco Supervisor Engines (1)
- Cisco UCS Manager (1)
- Cognitive Campus (1)
- Cost of Downtime (1)
- Dell EMC Data Domain (1)
- Edge Switches (1)
- Fabric Extenders (1)
- GRE Tunnel (1)
- HPE BL (1)
- Juniper SRX (1)
- Nexus Switches (1)
- Nutanix (1)
- Optics (1)
- PowerEdge R740xd (1)
- STP Extension (1)
- Sparing Integrity Program (1)
- Switched Virtual Interface (1)
- TCP (1)
- UCS Fabric Interconnects (1)
- hyperconverge (1)
- April 2024 (2)
- March 2024 (1)
- February 2024 (2)
- January 2024 (1)
- December 2023 (1)
- November 2023 (2)
- October 2023 (1)
- September 2023 (3)
- August 2023 (5)
- July 2023 (2)
- June 2023 (4)
- May 2023 (5)
- April 2023 (8)
- March 2023 (7)
- February 2023 (5)
- January 2023 (2)
- December 2022 (3)
- November 2022 (3)
- October 2022 (8)
- September 2022 (9)
- August 2022 (9)
- July 2022 (8)
- June 2022 (9)
- May 2022 (5)
- April 2022 (3)
- March 2022 (1)
- February 2022 (2)
- November 2021 (2)
- October 2021 (1)
- September 2021 (2)
- August 2021 (2)
- July 2021 (3)
- June 2021 (2)
- May 2021 (4)
- April 2021 (4)
- March 2021 (2)
- February 2021 (1)
- January 2021 (2)
- December 2020 (2)
- November 2020 (2)
- October 2020 (2)
- September 2020 (2)
- August 2020 (4)
- July 2020 (5)
- June 2020 (4)
- May 2020 (6)
- April 2020 (2)
- March 2020 (1)
- February 2020 (2)
- January 2020 (2)
- December 2019 (1)
- May 2019 (2)
- April 2019 (5)
- February 2019 (1)
- January 2019 (3)
- December 2018 (1)
No Comments Yet
Let us know what you think