In this Hub and Spoke Design, the Hubs are acting as ABRs to interconnect the non-backbone areas where the spokes resides. Route Summarization helps to reduce the size of the LSDB and the Routing Table, especially on the spokes. While Route Summarization is a must in large network, it can causes some suboptimal routing, for example, with links failure, any spoke can be used as a transit to reach another spoke in a non-backbone area or some networks in the backbone area behind the Hubs.
To better illustrate this issue and how to solve with an interesting feature. Let's dissect the folowing topology.
The Hubs currently are connected to Spokes SP-101 and SP-102 on area 100 while the area 200 is used with spokes SP-201 and SP-202.
The hubs have a connection to backbone area where some networks are advertise by some backbone routers.
As mentioned, Route Summarization helps to reduce the size of LSDB and Routing Tables on the Spokes Routers.
In a Multi-area design, ABR is responsible to summarize multiples Type-3 LSAs for specific subnets into a single Type-3 LSA respresenting the summary network.
The idea is to summarize from a non-backbone area to others areas and optionally from the backbone area to all non-backbone areas.
This is done by configuring both Hubs to inject a single Type-3 LSA for 10.1.0.0/16 into the backbone area and area 200 - and a single Type-3 LSA for 172.16.0.0/16 into the backbone area and area 100.
Let's focus on the Type-3 LSA for 10.1.0.0/16.
The SP-201 in area 200 will receive two Type-3 LSAs from Hub1 and Hub2 for the summary route with the SAME metric 2.
SP-201 compute the total cost by adding: the metric listed in Type-3 LSA (2) + Metric to reach the ABRs (1).
It find two equal cost inter-area route:
-Inter-area route via HUB1 with metric 3. The packet destined to SP-101 for ex is : SP-201 > HUB1 > SP-101.
-Inter-area route via HUB2 with metric 3. The packet destined to SP-101 for ex is : SP-201 > HUB2 > SP-101.
SP-201 will install a load balancing with two inter-area routes through the HUB1 and HUB2 to reach the networks behind SP-101 and SP-102 in area 100.
The important point you should consider before continuing with our explanation is the routing table of HUB1 and HUB2 and which routes is used to reach the networks behind SP-101.
For example, HUB1 is currently using an intra-area route with SP-101 as the next-hop. This intra-area route has better metric (2) than the metric through the secondary path via SP-102 > HUB2 > SP-101 with metric 4. Same thing for HUB2.
Once again let's focus on HUB1.
Now if the link between SP-101 and HUB1 fails. HUB1 will remove the intra area route to reach the specific subnets behind SP-101 and installs intra-area route via SP-102 > HUB2 > SP-101. Now from SP-201's perspective which is our concern.
If you do sh ip rou, you will find (still) two inter-area routes to the summary network with the same computed metric before the failure.
-Inter-area route via HUB1 with metric 3.
-Inter-area route via HUB2 with metric 3.
HUB1 is still advertising the Type-3 LSA that includes the specific subnets of SP-101 (and SP-102), so SP-201 will load balance accross two paths for packet destined to subnets behind SP-101, but when packet arrives at HUB1, it gets routed by HUB1 with the path : SP-102 > HUB2 > SP-101, therefore SP-102 is used as a transit to reach the networks behind SP-101.
The load balancing occurs as follow:
1- Through HUB2 > SP-101.
2- Through HUB1 > SP-102 > HUB1 > SP-101 (SUBOPTIMAL ROUTING with SP-102 as a transit).
HUB1 is still advertising the Type-3 LSA that includes the specific subnet of SP-101, SP-101 and SP-102 are not aware. Spokes do not see the routing changes on other areas because the summary route, in essence, hides these changes on area 100.
The first Solution : is to re-configure the link between ABRs in area 100, so that the HUB1 will use the intra-area route HUB1 > HUB2 > SP-101 with a better metric 3 than the path SP-102 > HUB2 > SP-101 with metric 4.
This solution is not scalable as we need additional link between ABRs for area 200, and with several spokes and sites with 50 non-backbone areas, we need 50 physical Link, each link in separate area.
The best solution and more scalable is to use the multiarea adjecency described in RFC 5185. The OSPF Multiarea Adjacency feature allows you to configure a link in multiple areas.
By default, an interface can only belong to one OSPF Area. When Multi-Area Adjacency is configured on an interface, the OSPF routers form more than one Adjacency (ADJ) over that link. The Multi-Area interface is a logical, point-to-point interface over which the ADJ is formed.
So in this case with a single link we avoid suboptimal routing with spoke as a transing by configuring the same link in 50 areas.
On both Hub.
HUBx(config-if)#int e1/1
HUBx(config-if)#ip ospf 1 100
HUBx(config-if)#ip ospf multi-area 100
HUBx(config-if)#ip ospf multi-area 200
HUBx(config-if)#ip ospf multi-area 300
HUBx(config-if)#ip ospf multi-area 400
HUBx(config-if)#ip ospf multi-area 500
.....SO ON
