Junos OS

I think I understand the key differences between the three types of routes, but could you give me some examples of situations where one option would be more appropriate than the other two?

Hello Ahsoka,

Here's a link of a case study that covers the 3 types of routes:

 http://www.juniper.net/techpubs/software/junos/junos62/swconfig62-policy/html/policy-framework-config24.html

In a nutshell:

- A static route is the most obvious. You need to be able to reach a certain prefix and you specify the next-hop. This is useful when you are not running dynamic routing protocols and/or when you want to override what a dynamic protocol dictates (since the protocol-preference for a static-route is lower -preferred- than that of any dynamic RP).

- An aggregate route is a route you define but which is not used for forwarding traffic (next-hop is discard or reject). It is purely used to advertise this router's connectivity which is why it needs at least one contributing route (a route which belongs to the advertised subnet but with a longer mask - these are the ones used to forward the traffic). Typically, the aggregate route would be advertised into BGP (if it is active thanks to contributing routes) - BGP does not like dealing with routes which are too specific - it prefers aggregates.

- A generated route is technically an aggregate route but which can be used to forward traffic. Traffic which matches the generated route (and not more specific routes) will be forwarded using the same next-hop as the first contributing route. A generated-route is typically combined with a policy to match which routes we want to be contributing and thus used as NHs. The generated-route is typically the default 0/0 with a policy matching to upstream routes - ie: provide connectivity if certain upstream routes exist.

HTH,

/david 

Hi David,

Sorry to sound like a fusspot but Im trying to understand "generated routes". Im picking  this sentence apart word by word but still cant get it.

Traffic which matches the generated route will and not more specific routes will be forwarded using the same next-hop as the first contributing route.

Do you mean that more specific routes will not be forwarded?

Hi Paula,

Re-reading my sentance, I can see why you're having trouble  

Let me rephrase it:

"Traffic which matches the generated route (and not more specific routes) will be forwarded using the same next-hop as the first contributing route."

This means (and this is simply a general rule of routing - not specific to generated routes) that traffic matching more specific routes will be forwarded according to those more specific routes. This is where it gets a bit tricky: like aggregate routes, generated routes are active if they have at least one active contributing (ie: more specific) route. But aggregate routes rely on the more specific for forwarding, whereas generated routes do not (or else they would not be of much use).

In other words, an aggregate route will typically have many contributing routes which are the ones actually used for forwarding traffic. Generated routes will typically have fewer contributing routes (maybe 1 or 2) and it is the generated-route itself which is used for forwarding traffic (that matches the generated-route without matching the more specifics) but it derives the next-hop from the first contributing route.

I hope this is clearer.

Regards,

/david 

Ah ha! Ok i think I get it. thanks.

So is it possible then in principle to have the more specific routes going to a differnt next hop than the "generated route" itself?

Also, when you say the "first contributing route" is that the numerical first within the address range of the generated route or is it the first that was configured.

I know its a bit of an oddball question but im just trying to fully understand for my JNCIS exam and theres not much about this stuff in the documentation.

thanks again 🙂

Paula

Hi Paula

You don't have to dig this far for your JNCIS

Indeed, it is possible to have certain more specific routes that point to different next-hops.

The correct syntax is actually "primary contributing route" and it is based on:

 - route with lowest protocol preference (eg: statics are preferred)

 - route with numerically lowest IP address as tie breaker (eg: 10.1.1.0/24 is preferred over 11.1.1.0/30)

Regards and good luck with the JNCIS 

/david 

Thats great,

Thanks,

Paula

- route with numerically lowest IP address as tie breaker (eg: 10.1.1.0/24 is preferred over 11.1.1.0/30) ?

If generated route is based on its contributing routes, would the generated route have a prefix/mask of 10.x.x.x/7, if was being generated on the basis of the above two mentioned specific routes in your example? With the NH being that from 10.1.1.0/24?

look at thsi case study and all will be clear

http://www.juniper.net/techpubs/software/junos/junos62/swconfig62-policy/html/policy-framework-config24.html

Hello,

I am sorry for cutting in between but I was also a bit confused about the diff b/w generated and aggregated routes. I understand the point you have made but there is one thing more that is still confusing me.

If the generated route needs contributing routes to get generated, and that the traffic which does not match the more specific contributing routes gets routed by the supernet sort of generated route, does that in a way sends or routes traffic which could be for a different subnet from the same major network, but gets sent to the NH that the generated route gets from its first contributing route?

Why Use a Generated Route?
It is a question that gets asked over and over again, so don’t feel bad for asking. The examples
in the chapter are constructed to show off the features of the JUNOS software, but do not nec-
essarily represent real-world uses. Let’s examine a potential use of a generated route.
Suppose you, an ISP, have a customer who would like to purchase service from you for Internet
connectivity. This customer also has similar arrangements with other ISPs. You have been
requested to use BGP to send this customer a default route (0.0.0.0 /0) only if your upstream
connection to the Internet is working. The question then becomes, “How best to do this?” Let’s
examine the options:
 A default route already exists in your network. Depending on your network environment,
this route may not represent your connectivity to the Internet. While functional and
dynamic, this may not be the best choice.
 You can configure a static route, which will be active and advertised as long as the router
has working interfaces. It will not be removed if your upstream connectivity is lost. This
approach probably is not a good idea.
 You can configure an aggregate route, one that will represent your upstream connectivity
but also represent your internal connectivity. (All possible routes will contribute to a default
route!) The downside of an aggregate route is that route lookups matching the default will
be dropped from the network. The only next-hop options are reject and discard. Unless the
router connected to the customer has every possible route in its routing table, this is not
likely an option.
 You can configure a generated route. The pros and cons are mostly the same as with an
aggregate route. Of course, with an IP next hop, the generated route can forward packets
matching the default route to some other destination. This sounds like the best option so far.
The only real issue with the generated route is that you need a way to ensure that the route dis-
appears if your upstream connection is lost. This is solved with a routing policy. This policy
should accept only a single route in your routing table that represents your connectivity. A
route to the root DNS servers in the Internet might be a good one to choose. The policy should
further reject all other routes from contributing to your generated route. In this fashion, the
generated route will have only one possible contributing route—your upstream connectivity
route. Should the route be lost from your routing table, the generated route is removed and you
stop advertising a default route to your customer.

JNCIA Study Guide.