JNCIS-SP: Aggregate and Generated routes.

To have look at aggregate and generated routes, I have configured an OSPF adjacency between R9 and R14 and an EBGP between R14 and R10.

R9 has an export policy and will inject static routes to R14. R14 is doing EBGP with R10 and has an export policy that will accept ‘protocol aggregate’.



scenario


Let’s start with the configuration of an aggregate route on R14. The aggregate route will, when redistributed, prepend an autonomous system. The configuration of the aggregate route is as follows;



scenario


By default, the aggregate route has a next-hop of reject and will only be placed in the routing table when there are active routes that fall inside the range of the aggregate route.



scenario


Let’s activate the generated route on R14 by injecting the 9.0.0.0/24 route into OSPF. As soon as the route is advertised by R9, the aggregate route is placed into R14’s routing table;



scenario


By looking at the extensive aggregate information, we can see what individual routes are contributing to having it been placed into the routing table.



scenario


Next, I’ll change the aggregate route to a generate route. The main difference between an aggregate and generate route is that the generate route will derive the next-hop from the routes contributing to it. In our case, the next-hop will be the address of R9.

First, let’s remove the aggregate and create a generate route:



scenario


Next, let’s have a look at the details of the generate route:



scenario


To EBGP neighbors, the contributing routes (and possible instability) will be masked. Let's alter the amount of contributing routes that R9 is sending to R14 like this;



scenario


And observe what is received on R10:



scenario


Anyway, the aggregate and generate route can be a nice way to hide routing-instability. The generate route is a nice route of last-resort since the next-hop is inherited from the contributing route.

That’s it.

30-8-2014