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

In the 90s, the big fashion was Tamagotchis. 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 forwarding plane, 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.

Think of route summarisation as like doing a kind gesture to your neighboring routers – the sort of kind 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 few ways you can summarise routes in Junos

One is simply to make a normal static route, 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’s dropping traffic. The more specific prefixes will all have their own individual next-hops – and 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 network in our routing table. Which is exactly what we want to happen!

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

[edit]
root# set routing-options static route 5.0.0.0/8 discard

root> show route

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

5.0.0.0/8 *[Static/5] 00:00:05
             Discard

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 5.0.0.0/8 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.

 

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 (the Junos equivalent of administrative distance) of 130, as opposed to 5 for a static route
— 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 one big difference though, and that’s 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 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 f*cking (fucking) 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.

 

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.

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.

Thank you very much for reading my post! If you enjoyed it, please share it on your favourite social media platform of choice (MySpace, Bebo etc). The more readers I get, the bigger my smile!

2 thoughts on “JUNOS: AGGREGATE ROUTES VS GENERATE ROUTES – HOW TO SUMMARISE ON JUNIPER ROUTERS

  • July 3, 2018 at 2:56 pm
    Permalink

    Nice, light touch…gets the info across but keeps my mind engaged with a bit silliness. Well done!

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *