JNCIP-SP: summarization through an aggregate route.

In this lab we will examine one of two possibilities to summarize external LSAs. What we will add to the lab layout is the following;


R5 will advertise 4 routes to R3. On R3 we will turn the 4 prefixes into 1 summarized range. In Junos it is not possible to use the area-range command to summarize type 5 external-LSAs on an ASBR. Instead, the two ways to summarize External-LSAs in Junos are;
1. through the redistribution of an aggregate route.
2. by using the nssa area-range configuration command.

Since I'll cover NSSA areas in another article, I'll stick to the first option.

To start summarizing the range of addresses advertised in BGP by the R5, we start of with the creation of an aggregate route.

An aggregate route in Junos is a route that becomes active when there is a contributing route. A contributing route is a route that falls within the prefix range of the aggregate route itself. In our example, the routes advertised by the BGP neighbor will be the contributing routes needed to activate the aggregate route.

The aggregate route will be referenced in the OSPF export policy. This way, we can summarize the prefixes learned via BGP and inject only the prefix into OSPF.

To start, first, let's configure and verify the aggregate route;

set routing-options aggregate route

Now, let's have a look at the following printout:


The first command shows us that we are learning 4 routes in BGP. The second command tells us that all four of those routes are seen as contributing routes by the aggregate.

The nice thing about using an aggregate (instead of a static route with reject) is that the aggregate will only appear in the routing-table as long as there is at a contributing route. The aggregates next-hop 'Reject' will not have any effect since the BGP-learned routes are more specific.

Anyway, the aggregate route is there and it is active. Next thing is to create and apply an export policy in OSPF:

set policy-options policy-statement EXPORT-AGGREGATE from protocol aggregate
set policy-options policy-statement EXPORT-AGGREGATE then accept
set protocols ospf export EXPORT-AGGREGATE

After the configuration is committed, we can observe the following on R3:


Here we can see that the rest of the OSPF network will only learn about this one /22 prefix effectivly summarizing the prefixes learned via BGP.