JUNOS: AGGREGATE ROUTES VS GENERATE ROUTES – HOW TO SUMMARISE ON JUNIPER ROUTERS

In 2016, the big fashion was skinny jeans. In 2017 it was fidget spinners. And of course, in 2018 there’s only one trend on everyone’s lips: route summarisation.

Yes Sir/Madam, summarising prefixes is the craze that’s sweeping the world. Beyoncé’s doing it. All the kids want in on it. Even the Queen is said to enjoy nothing more on a Sunday evening than sitting in front of the TV with a pen and paper, and working out the best way to reduce the size of her routing table. Just because you’re rich doesn’t mean you can’t aim for an efficient use of your router’s memory, after all.

Of course, everything I’ve said so far is a lie. Let me make it up to you with some truth: in Junos there’s three ways to summarise routes. Want to know what they are? Well gosh damn, you’ve come to the right place!

 

A QUICK RECAP: WHAT IS A SUMMARY ROUTE?

Summary routes take one or more network prefixes, and combine them into one bigger prefix.

For example, 192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24 and 192.168.3.0/24 can be summarised as 192.168.0.0/22. Advertising the one summarised prefix to your peers is far more efficient than advertising the four more specific routes. It keeps the routing table smaller, and it also means that your peers don’t need to worry about tiny flaps in your network. The interface hosting 192.168.2.0/24 could go down, but the routers further down the way wouldn’t need to worry about that: it doesn’t change the fact that the entire /22 still exists in the same place.

Think of route summarisation as a bit like doing a nice gesture to the routers in your network. The sort of nice gesture that, for example, you might do to your grandfather, or to a dog that saved your life in March 1987.

 

SUMMARY ROUTES IN JUNOS

There’s a three ways you can create summary routes in Junos

The first is simply to make a normal static route for the entire summary, but with a next hop of “discard”.

Now, if this is your first time learning about summary routes, you might be wondering: “Wait a second – why would I want to discard the traffic?” It seems counter-intuitive at first, doesn’t it? But remember: it’s only this summary route that has a next-hop of discard. The more specific prefixes will all have their own individual next-hops. And remember, a router always believe the most specific prefix in its routing table.

In other words, the traffic will only drop if there isn’t a more specific prefix in our routing table. Which is exactly what we want to happen! In our scenario above, if 192.168.2.0/24 were to disappear, then we would indeed want that traffic to drop.

Let’s pretend we had a load of networks in the 192.168.0.0/16 range. Here’s how you’d summarise it:

[edit]
root# set routing-options static route 192.168.0.0/16 discard

root> show route

inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.0.0/16 *[Static/5] 00:00:05
             Discard

Once we’ve made this summary static route, we could then create a routing policy to redistribute it into any protocol we like.

The problem with using static routes to summarise is that the summary stays in your routing table permanently. In the example I configured above, I don’t actually have any sub-networks on my device in the 192.168.0.0/16 range. And yet, the summary route is in my routing table. This behaviour may or may not be what you want, but generally speaking you’ll want the summary to disappear if all the sub-networks also go down. And to achieve that, Junos gives us two other options. One of them is called aggregate routes, and the other is called generate routes. Let’s take a look at both of them.

 

AGGREGATE AND GENERATE ROUTES: WHAT’S THE DIFFERENCE?

Aggregate routes and generate routes are very similar in a lot of ways:

• They both create summary routes in the routing table
• They both have a route preference of 130, as opposed to 5 for the static route we just made (route preference is the Junos name for what some vendors call administrative distance)
• Perhaps most importantly, they both only appear in the routing table if there’s at least one active, more specific subnet of the summary in the routing table – what Junos calls a “contributing” route
• They both like long romantic walks on the beach (I expect)

There’s two big differences though.

The first is their next-hop behaviour. With an aggregate route, you can only have a next-hop of discard or reject. Both of these drop the traffic, but if you choose reject then Junos will also send an ICMP Unreachable message in reply. If you don’t specify which one you want to use, the traffic is rejected by default.

Generate routes, on the other hand, do indeed let you have a next-hop IP address. The summary route’s next-hop is taken from the “primary” contributing route’s next-hop. Which route is chosen as the primary, you ask? Here’s the process:

• Choose the route with the lowest route preference (aka administrative distance)
• If there’s more than one route with the same preference, use the lowest IP address number as a tie breaker

Only routes that have a working, valid next-hop can contribute to a generate route. That’s important to remember. It means that the presence of a directly-attached LAN will NOT contribute to a generated route, because there’s no clear next-hop.

Also, here’s a fun fact: generate routes also let you choose a next-hop of discard – but not reject. Why? I’ve no idea. My guess – and I stress the word guess – is that you’d choose generate when the presence of a next-hop is important, and you’d choose aggregate when you want to include directly-connected interfaces. Then again, when I was six I thought that televisions were full of tiny men and women putting on miniature plays all day, so don’t listen to my theories.

The other difference is what exactly counts as a contributing route. In an aggregate route, absolutely any prefix in the routing table counts as a contributing route. By contrast, generate routes will only accept a contributor if it has a next-hop to somewhere else. In other words, directly connected interfaces don’t count as contributors to generate routes.

This is actually quite handy. Imagine that you have a CPE with a single WAN link out, and imagine that you want to define a default route with a next-hop of a BGP peer at the other end of the WAN link. However, you only want the default route to go live if you’re learning prefixes by BGP. This is a great use case for a generate route. If you’re learning prefixes by BGP, the generate default will be live. If BGP goes down, the only prefixes in your router’s routing table will be ones from directly connected interfaces, which don’t count. Bye bye default route!

 

LET’S CONFIGURE THEM!

Take a look at my sweet topology. Let’s pretend I’ve got a big network of routers, with eight prefixes that are ripe for summarisation. Notice that this time I do indeed have lots of prefixes in the 192.168.0.0/16 range.

CONFESSION: In reality I haven’t got a big network of routers at all: I just used Google™ to find a picture of a cloud, and then I put some numbers on top of it. This is fine for my demonstration, but if you’re an actual internet provider then please bear in mind that this won’t work in the real world. You’ll need to buy actual routers, not just draw a picture of a cloud and put it up in your data centre. Even if your frame the picture, it still won’t work. Your customers will be very angry with you if you try to do this, and they will sue you for a lot of money.

Anyway, the point is that there’s eight small networks in my cloud, which I want to summarise on Junos_R1. I then want to advertise this summary to my peers.

For our lab, let’s just add two of these prefixes into R1’s routing table, one from each range that we want to summarise. This will demonstrate that we don’t need every single prefix in R1’s routing table for the summary to go live, and that we actually only need the one “contributing” route:

set routing-options static route 192.168.40.0/24 next-hop 192.168.1.1
set routing-options static route 192.168.60.0/24 next-hop 192.168.1.1

Now we’ve added the smaller networks, let’s add our summary route. We’ll make one an aggregate, and one a generate. Here’s the syntax for each:

set routing-options aggregate route 192.168.40.0/22
set routing-options generate route 192.168.60.0/22

 

LET’S TEST!

Use the command show route protocol aggregate to see both your aggregate AND your generate routes:

root> show route protocol aggregate

inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
 + = Active Route, - = Last Active, * = Both

192.168.40.0/22 *[Aggregate/130] 00:02:30
                   Reject
 192.168.60.0/22 *[Aggregate/130] 00:02:30
                   > to 192.168.1.1 via ge-0/0/1.0

Notice that there isn’t a “show route protocol generate” command. Why? Because Juniper are smarter than us. Don’t question their superior reasoning. We all owe a gratitude to Barry Juniper (CEO of Juniper) for his continued quest to make things easy and simple to understand.

If you want to see whether a route is an aggregate or a generate route, you need to use the command show route protocol aggregate detail. Notice that the 192.168.60.0/22 network has a Next Hop of 192.168.1.1, plus the “Generate” flag is set:

root> show route protocol aggregate detail

inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
[ output trimmed for brevity ]

192.168.60.0/22 (1 entry, 1 announced)
 *Aggregate Preference: 130
 Next hop type: Router, Next hop index: 569
 Address: 0x934c208
 Next-hop reference count: 7
 Next hop: 192.168.1.1 via ge-0/0/1.0, selected
 State:
 Age: 6:27
 Task: Aggregate
 Announcement bits (1): 0-KRT
 AS path: I
 Flags: Generate Depth: 0 Active
 Contributing Routes (1):
 192.168.60.0/24 proto Static

EXPORTING THE SUMMARY ROUTES

Now our summary routes are in the routing table, we can make a policy for it, and advertise it to our peers. Here’s the syntax. Try it at home!

set policy-options policy-statement SUMMARY-POLICY term MY-SWEET-SUMMARY from protocol aggregate
set policy-options policy-statement SUMMARY-POLICY term MY-SWEET-SUMMARY then accept
set protocols bgp export SUMMARY-POLICY

 

THAT’S IT!

Do you summarise routes in your network? Have you ever come across any problems? What was your solution? As always, I’d love to hear your stories in the comments, so please leave a note saying hi! Think of it like friendship. Though let me be absolutely clear: my real-world friendship costs two million US dollars a year.

If you’re on Mastodon, follow me to find out when I make new posts. (2024 edit: I’m also on BlueSky nowadays too. I was once on Twitter, but I’ve given up on it, on account of… well, I don’t need to finish that sentence, do I.)

And if you find my blog useful or entertaining, I’d love you to share it with your friends and co-workers, whether via a Twitter/Facebook/LinkedIn post, or just emailing it to them directly. Spread the world, and I’ll be inspired to write even more posts.

And if you fancy some more learning, take a look through my other posts. I’ve got plenty of cool new networking knowledge for you on this website, especially covering Juniper tech and service provider goodness.

It’s all free for you, although I’ll never say no to a donation. This website is 100% a non-profit endeavour, in fact it costs me money to run. I don’t mind that one bit, but it would be cool if I could break even on the web hosting, and the licenses I buy to bring you this sweet sweet content.