In today’s posts, we will start discussing the additional applications also provided by OSPF summarization. OSPF summarization can be also used for Traffic Engineering and Filtering.
Just to recap: OSPF scalability is achieved by summarization of the topology using OSPF areas and network prefixes summarization. Now, OSPF summarization can only be applied for inter-area and external routes. The Inter-Area summarization is performed in ABRs, it summarizes Type-1 into Type-3 LSAs. The external routes summarization is performed on ASBRs, it summarizes Type-5 into Summarized Type-5 LSAs and type-7 into Summarized Type-7 LSAs.
When summarization is done, the discard route (route to Null0) is automatically created. This is a loop prevention mechanism used to discard routes if no more specific route to a network destination exists. In OSPF, summarization must be done in a manual way. Please take a look at the previous post for details in OSPF summarization and its configuration.
Using OSPF summarization for Traffic Engineering:
We can perform OSPF traffic engineering with summarization when we have multiple exit points out of an area or multiple exit points out of the autonomous system. It is achieved using longer prefix match over shorter prefix match routing. In other words, route traffic over more specific routes than summary routes. Let’s use the following topology to illustrate how traffic engineering with summarization works:
Here you can download the diagram and configuration files: TE with OSPF Summarization – Part I.
Let’s take a look to the routing table in R4:
As can be seen in the above output, R4 (ABR for area 20) has inter-area routes (Red) coming from R5 and R7 belonging to area 20 respectively with its corresponding /21 summary discard routes pointing to Null0.
R4 also has external routes (Above in Blue) coming from R6 (EIGRP Domain) as shown below.
Now, the external routes are been load-balanced between R2 and R3 ABRs. Let’s take a look to the LSA corresponding to the prefix 172.16.1.0.
The LSA corresponds to a Type-5 External LSA, the Advertising Router is R3 (RID 0.0.0.3). This field corresponds in this case to the “Elected Translator Router”, or the router in charge to translate from Type-7 LSA into Type-5 LSA, however, the route comes from R1 (LINK ID 1.1.1.1) which is the router doing the redistribution into OSPF. Now let’s take a look to the LSA corresponding to the link-ID 1.1.1.1:
As can be seen in the output, the Type-3 LSAs corresponding to the link-id 1.1.1.1 has two possible routes. From R2 (Advertising Router: 0.0.0.2) and R3 (Advertising Router: 0.0.0.3) with identical metric. Thus, the route is been load-balanced.
Now, with this information let’s do some traffic Engineering:
Goal:
Traffic from the networks 10.0.0.0/21 in R4 (Area 0) and the whole Area 20 must use R2 to reach the 172.16.0.0/16 networks in the EIGRP domain.
At first hand we know the Totally Stubby Area 20 will automatically generate a default route, it will have into its link-state database Type-1 and Type-2 LSAs containing intra-area information and a Type-3 Summary LSA with the default route pointing to R4, which is the only way out to reach other areas and external routes. This is the case for R5 and R7 respectively as shown below: (Only R5 information shown by brevity)
We also know the routes to the external EIGRP domain are being load-balanced between R2 and R3 in R4:
So, let’s apply the Summarization in the ASBR (R1) and examine the routing table in R4 again:
In R1 (ASBR):
!
router ospf 1
summary-address 172.16.0.0 255.255.0.0
!
As shown in the above output, the routing table of R4 now has a summary 172.16.0.0/16 route; the route is still load-balanced. The requirement is to route the traffic to the external EIGRP domain via R2. Here is where the tricky part comes.
Let’s take a look at the link-state databases in R2 and R3, in particular to the Type-5 and Type-7 LSAs.
As can be seen, the ABRs translated Type-7 into Summarized Type-7 LSAs and as expected a Type-5 summary LSA was generated by the elected Type-7 to Type-5 Translator Router. In this case R3 (RID 0.0.0.3). R4 will receive only the Summarized Type-5 LSA; Type-7 LSAs are not allowed out of NSSA areas, the ABR connecting NSSA areas will generate a Type-5 LSA to advertise the external routes on behalf of the ASBR.
But, what can we do to route the traffic only from R2? Currently, we have two identical paths with identical metric. Let’s recap and change the approach. For traffic engineering with OSPF summarization to work is needed a summary route in one of the ABRs and more specific routes in the other. So, let’s undo the previous change and summarize in the one of the ABRs.
In R1 (ASBR):
!
router ospf 1
no summary-address 172.16.0.0 255.255.0.0
!
In theory, if we summarize the loopbacks of R6 (EIGRP Domain) into 172.16.0.0/16 in R3, the more specific routes in R2 will be preferred. Let’s give it a try.
In R3 (ABR):
!
router ospf 1
summary-address 172.16.0.0 255.255.0.0
!
Now let’s take a look to the routing table in R4:
Wait a minute. It didn’t work! Let’s find out why?
Let’s take a look again to the link-state databases in the ABRs, in particular to the Type-5 and Type-7 LSAs.
As can be seen in the above output, both ABRs have Type-7 LSAs flooded in the NSSA area from the ASBR (R1). They also have a Type-5 LSA corresponding to the summarized prefix 172.16.0.0/16, but it’s not supposed to have in R2 Type-5 LSAs with specific routes? Something likes the following:
Well, let’s take a closer look to the external LSA in R2:
Have you noticed the problem? The forwarding address of the Type-5 LSA is set to null (0.0.0.0). This means that the route is reachable only via the advertising router. You may be thinking that the advertising router is the ASBR (R1) and this is correct in part, but you have to remember when multiple ABRs are present only one is elected as the Type-7/Type-5 translator.
The ABR R3 was elected translator because it has higher Router-ID (RID) configured. R3 has suppressed the most specific prefixes and replace them with a single Summarized Type-5 LSA and then it flooded to all routers within the area.
The way to solve this task is to apply the summarization in R2 and make it the Type-7 to Type-5 router translator. As you may know, the election is “automatic”, this means that changing the RID in R2 to something higher it will change the role to the Type-7/Type-5 translator. But, it is also required when changing the RID in an OSPF-enabled router clearing the process. Clearing the OSPF process is a disruptive change, so plan accordingly if you choose this path.
Another way to do this it’s instructing the ABR R2 to become always the Type-7/Type-5 translator. This is done in the nssa area definition, adding the keywords translate type 7 always. This change is non-disruptive.
Let’s make the change and give it a try.
In R2 (ABR):
!
router ospf 1
area 30 nssa translate type7 always
summary-address 172.16.0.0 255.255.0.0
!
As seen in the above outputs, the goal was achieved. Traffic from the loopbacks in R4 and networks in Area 20 now traverses R2 as the primary path to reach the EIGRP domain. Also, redundancy is in place. If a failure occurs in R2, then R3 will advertise the summary route.
It is time to close this long post. In the next one, we will discuss traffic engineering with inter-area summarization. Thank you for visiting.
R&S Journey 