Multi-Area OSPF

Submitted by rayc on Tue, 11/30/2021 - 08:45

An OSPF area is a logical grouping of routers into a specific OSPF area (Area 0, the backbone area by default). Using a single area OSPF design has it's benefits in that it can simplify your network, however there are some drawbacks to using a single area when your OSPF network gets too large. 

  • If there is a link flapping in the network, all OSPF routers will run a full SPF calculation every time this occurs. 
  • The LSDB can become too large to manage and consume router CPU and Memory resources. This isn't so much a concern with modern routers. 
  • Having a larger LSDB means that SPF calculations take longer.
  • You cannot summarise routes in a single area design

 

Segmenting your network into multiple OSPF areas can make your network more manageable and with a good OSPF design, can make your network topology converge even faster with proper use of area types and route summarisation.

There are a few things that need to be taken into consideration when using multiple OSPF Areas though to ensure a loop free topology. The biggest being that Area 0 is the backbone area and if a link fails, will not be discontiguous. Other things to take into consideration would be where the Area Boundaries will be so that summarisation is most effective, also what type of Area's will you use throughout your network. For example, if you're running a DMVPN overlay for your WAN, you may be able to make that a separate totally stubby area for all of the WAN end devices.

When an OSPF router becomes an ABR (Area Border Router), it will create and flood Type 3 LSAs into the connected areas to advertise the other area's networks. These routes show in the route table as IA (Inter Area) routes. 

output of the route table showing OSPF IA routes

As you can see we have multiple ECMP routes for our Inter Area routes in this example. Let's take a closer look at the route to the 172.16.1.0/24 network. We can see that the route is an Inter Area route, and the AD is the default for OSPF of 110 and the route has a metric of 201. This is the cost of all interfaces in the OSPF path to reach the network 172.16.1.0/24 through the ABR. 

Let's take a look at an example of a multi area OSPF design. 

Multi Area OSPF topology

In the above topology, we have 4 OSPF Areas (area 0, 10, 20 and 30) and a router running EIGRP AS 100. R2 and R4 are ABR routers for area 0 and 10 and R5 and R6 are ABR routers for Area 0 and 20. Notice Area 30 is not connected directly to Area 0? I've done this on purpose to illustrate both why it should never be done, and how to remediate it. R3 in this topology is also an ASBR router as it connects to both Area 0 and runs EIGRP between itself and R9. 

I'm not going to go through the configuration of OSPF here as that will be another post, but I will go through the routing information. If we use R3 as the central point and look at the route table of R3 we can see we have route's to all hosts except for routes in Area 30, as this Area does not connect to Area 0. 

output of show ip route from R3

If we take a look at the route table from R2 in the above example, we can also see that the R3 D (EIGRP) route along with the subnet for the interface that connects to R9, is shown as an E1 type route. If this was redistributed into OSPF using a Type 2 route, the route table output would show E2. The difference between a Type 1 and Type 2 route is the cost calculation. The Cost for a Type 1 route, is the cost from the router to the ASBR, plus the cost from the ASBR to the network, while the Cost of a Type 2 route, is just the cost advertised by the ASBR. 

output of show ip route ospf on R2 showing External Type 1 routes

Route Summarisation

Now, i've added several interfaces on R1 in our topology with IP's 172.16.1.0/24 - 172.16.8.0/24 in order to show how summarisation occurs as unlike in EIGRP, OSPF routes can only be summarised on an ABR. Let's now take a look at the route table of R3 again with the new OSPF routes.

output of the route table of R3 pre route summarisation

We can now see the routes advertised by both ABR routers R2 and R4 for the 172.16.X.X subnets. We have 2 options for summarisation here. In order to summarise these routes, We need to a) work out if we will potentially be adding more subnets to the R1 172.16.x.x range in the future or b) determine if the 172.16.x.x subnets will exist anywhere else in our topology (Although as long as we don't summarise 172.16.x.x anywhere else it won't really matter although that would be bad network design). So i've determined that there may be some growth in the future but not beyond adding a few extra subnets so let's find the lowest common network bit. To do this we need to break down the binary of the 3rd octet in our subnets.

172.16.1.0 = 172.16.00000001.0 -> 172.16.8.0 = 172.16.00001000.0

So the lowest common network bit, is the 5th bit in the 3rd octet making our common subnet a /20 or 255.255.240.0 This will allow us to use any subnet between 172.16.0.0 and 172.16.15.0. to configure summarisation we use the ospf router configuration subcommand area <id> range <network> <mask>.

configuring route summarisation on R2 ABR

Because we have two ABR routers, we need to configure the same command on both R2 and R4. If we now take a look at the route table on R3, we can see that the 172.16.x.x subnets, are now summarised to 172.16.0.0/20.

R3 route table post route summarisation

As I mentioned before about having other subnets inside the summarised range elsewhere on the network, while it's not best practice, it does work. Say we added the subnet 172.16.10.0/24 on R7 inside Area 20. The 172.16.10.0/24 subnet sits inside that summarised range, however because we're advertising the more specific route over the /20 route, Hosts can still reach the 172.16.10.0/24 subnet on R7. 

Example showing more specific route preferred over summary route

Route Filtering

You can also use the area range command to filter out LSA's by using the same command but adding the not-advertise keyword. This keyword tells the router to not create Type 3 LSA's for the networks within that range. The full command is area <id> range <network> <mask> not-advertise. I have removed the summary command from both ABR's and configured the not-advertise command to filter out the routes for 172.16.0.0/22.

Configuring LSA Filtering on R2

Now if we look at R3's route table we can see the 172.16.0.0 - 172.16.3.0 subnets are missing from the route table.

R3 route table post LSA filtering

The other way to to filter routes in OSPF is to filter the Type 3 Summary routes as the leave an area. You can achieve this by using an OSPF Filter-List. Again this can only be done on the ABR as routes leave or enter an Area. To filter LSAs in or out of an area on an ABR, use the OSPF router configuration subcommand area <id> filter-list prefix <prefix-list> <in|out>​​​​​​. A use case for this would be when using summarisation, you are limited to filtering entire ranges of subnets from being advertised. Using Area filtering, you can specify specific subnets to be permitted or denied from being sent or received.

For example, we already have 8 subnets in the 172.16.x.x range being advertised from Area 10, but what if we wanted to deny the specific subnets for 172.16.2.0/24 and 172.16.5.0/24 from be advertised into Area 0? This is where filter lists come in. To configure a filter list, you must first configure your prefix list to permit or deny specific routes. Once you have the prefix list configured you apply the filter list to the OSPF router process. Let's configure our filter list to prevent the 172.16.2.0/24 and 172.16.5.0/24 subnets from being advertised into Area 0.

Configuring Filter lists on R2

OSPF also supported the use of distribute lists. While every router in an area must have an identical LSDB, the routes that enter the RIB, can be altered using distribute lists. Distribute lists do not prevent  Type 1 LSAs from becoming Type 3 LSAs in a different area because the LSA generation occurs prior to the distribute list being processed, however it does prevent Type 3 LSA's coming from the backbone area from being generated into non-backbone areas as this happens after the distribute list is processed.

To configure a distribute list, use the ospf router configuration subcommand distribute-list <acl|prefix <prifix>|route-map <name>> in. Distribute lists can only be applied inbound on an ABR and away from Area 0. You cannot use a Distribute list on an ABR towards Area 0. In this instance, we want to filter say the 172.16.0.0/22 subnet range from being advertised into Area 20 via R5 so the Distribute list will be applied on R5.

Configuring a Distribution List on R5

If we now look at the route table on R7, we can see that the only route to the 172.16.0.0/22 subnet ranges are through R6 only.

Verifying the Distribution List configuration of R5

But what about Area 30 routes you ask? Because Area 30 does not connect to Area 0, LSU's will not be flooded throughout the other OSPF Area's at all. This is because LSU's are only flooded to Area 0 and the Area 0 ABR's will flood to all other Areas. If we look at the route table for R8, there are no learned OSPF routes at all even though we have OSPF neighbours. 

R8 route table and ospf neighbour output

There are three ways to address this OSPF issue. 

  • Redesign the OSPF Area tolopology so that all Areas are connected to Area 0
  • Configure OSPF Virtual Link across area 20
  • Configure a GRE Tunnel between Router R8 and R5 or R6

Virtual Links

An OSPF Virtual Link is a special type of connection that allows a router that is unable to connect directly to Area 0, to logically appear as though it is by transiting through another Area or multiple Areas (Yes that's correct, you can configure a Virtual Link through multiple areas). This is in essence similar to creating a tunnel through one Area into Area 0.

Example of how Virtual link works

When a virtual link is created through an OSPF Area, all messages are sent using unicast addresses to the ABR at the other end of the link. These messages will also have the do not age bit set in their LSU messages. The Do Not Age bit tells the router that there will be no reflooding of LSA's after the initial flooding. Remember that LSA's timeout usually after 30 minutes and are resent. Virtual link are not designed to be used as a permanent solution to this type of problem as they rely on the transit area for connectivity. 

When you configure a Virtual Link between routers, it must be between ABR's. These two ABR's will form a neighbour adjacency across the Virtual Link. It is also recommended to use Loopback interfaces as the RID's and configure the Virtual Links using these Loopback addresses as they are more stable than physical interfaces. Hello messages are still send over the virtual link and adjacencies are dynamically established. 

To configure a Virtual Link, use the command router ospf configuration subcommand area <id> virtual-link <router-ID> where the Area ID is the Area ID of the transit Area which in our case is Area 20. This configuration must be done on both routers that are to be the endpoints for the Virtual Link. 

Virtual Link Configuration on R7

This configuration also needs to be done on R5 and R6 if we decided to configure virtual links between both Area 0/20 ABR routers. 

Configuring the virtual link on R5

Notice the error messages about receiving incorrect OSPF messages from the wrong area ID. Once the virtual link was configured, the OSPF adjacency was established and we can confirm that using the command show ip ospf neighbor. If we now take a look at the route table of R3, we should see the OSPF routes for the Area 30 networks.

R3 route table after configuring the Virtual Link

As I said however, Virtual Links are not designed to be a permanent solution and should only be used as an interim solution until a more permanent solution can be implemented. 

GRE Tunnel

As I mentioned earlier, the other solution would be to create a GRE tunnel. A GRE Tunnel creates a virtual tunnel between two end points as a kind of VPN, only not private unless you configure some sort of IPSEC Encryption. When you use a GRE tunnel, the router receives the IP packet, and puts a unicast GRE header source and destination packet overtop and sends it. I'll explain more about GRE tunnels later but for now know that a GRE tunnel will allow for dynamic discovery of OSPF neighbours. For this solution, we need to create a GRE tunnel between R7 and R5 and have the tunnel interfaces in OSPF Area 30. I've configured the tunnel interfaces and GRE tunnel on both routers with the subnet 10.57.57.0/24 with R5 having an IP of .5 and R7 having an IP of .7. Next we need to configure both R5 and R7's OSPF process to enable to Tunnel interface 0 for OSPF in Area 30. 

Enabling OSPF on the GRE Tunnel Interface on R7

Straight away we can see that the neighbour relationship is up. Let's take a look at the route table on R3 and confirm that the path is over the GRE tunnel by running a traceroute to 8.8.8.8 which is the loopback interface on R8.

R3 route table after configuring the GRE tunnel

Again, GRE tunnels are also not a permanent solution to a discontiguous OSPF Area design and a more permanent design should be implemented so that the Area's all connect to Area 0.