If you’re a network engineer familiar with Cisco devices you are probably familiar with the “network” statement under routing protocols. If you’re a Cisco shop and you’re speaking BGP with a peer, you almost certainly use the network statement to announce your networks. This is the easiest method as it announces your network as long as there is at least one subnet of that route in your routing table.
Juniper has no concept of the network statement which means announcing your desired networks becomes a little more complex. It is complex but it also provides much more control.
First we need to look at what goes into generating an aggregate route. It can be as easy as:
set routing-options aggregate route 100.100.100.0/24 discardThis aggregate route can then be used in your BGP export policy to announce this network as long as a contributing route exists in your routing table. The easiest way to do this would be to add an address to your loopback.
set routing-options aggregate route 100.100.100.0/24 discard
set interfaces lo0.0 family inet address 100.100.100.1/32
set protocols bgp group TEST neighbor 1.1.1.1 export AGG_ROUTES
set policy-options policy statement AGG_ROUTES from protocol aggregate
set policy-options policy statement AGG_ROUTES then acceptIn this block we add the aggregate route, add a subnet to the loopback interface so that the aggregate route becomes active, and then we export routes from the protocol ‘aggregate’ to our BGP neighbor 1.1.1.1. This works, but what if we wanted to be a little more specific and avoid using a route from BGP or IS-IS or another protocols. In that case you would add a routing-policy to your aggregate route.
set routing-options aggregate route 100.100.100.0/24 discard
set routing-options aggregate route 100.100.100.0/24 policy AGGREGATE_FROM_DIRECT_STATIC_OSPF
set policy-options policy-statement AGGREGATE_FROM_DIRECT_STATIC_OSPF from protocol direct
set policy-options policy-statement AGGREGATE_FROM_DIRECT_STATIC_OSPF from protocol static
set policy-options policy-statement AGGREGATE_FROM_DIRECT_STATIC_OSPF from protocol ospf
set policy-options policy-statement AGGREGATE_FROM_DIRECT_STATIC_OSPF then acceptWe generate the aggregate route directly, via a static route, or via OSPF but excluded other protocols such as BGP or IS-IS.
But why use an aggregate route instead of a discard route?
Imagine you are announcing 100.100.100.0/24 and 100.100.0.0/22 from your router. Your router has all of the contained /24 networks attached as interfaces. 100.100.100.0/24, 100.100.0.0/24, 100.100.1.0/24, 100.100.2.0/24, 100.100.3.0/24. For the /22 network you can install a discard route which can be used in policy. You can do this because there are more specific routes to actually route traffic to. For the /24 you cannot have a directly connected interface route as well as a discard route of the same length as the directly connected interface route is more preferred so the discard route does not get installed. So now you have to create different policy based on how big your prefixes are. Aggregate routes help solve this issue as well as many others.
Here is what the routing table looks like when you have a local interface and a discard route of the same length. You can see that the local interface route is preferred. The Discard route isn’t installed and thus it is not used by other routing-policy.
Work, and stuff 