JunOS | Generate Routes

In a previous post, I’ve shown how we can use aggregate routes to optimise the routing table. Another way of achieving the same – though with different functionality, is by using Generate routes. 

Technically, generate routes are still aggregate routes and therefore, route advertisement is still governed by the same rules. The major difference from aggregate routes is that generate routes have an actual IP address as the next-hop destination and therefore, when a destination IP address is not successfully matched against any of the contributing routes, the packet is forwarded to the determined next-hop of the actual aggregate.

Generate routes have the following characteristics:

  • Generated routes need a clear/specific next-hop (an ip address):
    • Next-hop is chosen from the available next-hops set on the contributing routes;
    • As a result, directly attached interfaces do not contribute to the generated route since they don’t have a valid IP address next-hop
    • Exception: Next-hop cannot be set to discard; though it can be set to reject
  • The next hop of a generated route is the next-hop of the primary contributing route which is determined as below:
    • Matching the next-hop of the route with the lowest administrative distance (preference and preference2 attributes) out of all contributing routes (does it change?)
    • Matching the next-hop of the numerically lowest IP address out of all contributing routes

For this lab I will add an extra subnet configured on router R1; the subnet is 10.200.6.0/24. By using a generated route, we can still create an aggregate on R3 without risking that a packet destined for 10.200.5.0/24 (not an active member route) being discarded since the aggregate has a valid destination as the next-hop.


LAB TOPOLOGY

In the topology below, solid line arrows indicate routes configured on the device; dotted lines indicate flow of prefixes as dictated by the configured routing policy.

R1 has two directly connected networks configured as multiple IP addresses to Lo0.0 interface; these networks are 10.200.1.0/24 and 1.200.2.0/24. It has a static default route configured towards R2.

R2 is using static routes towards R1 so it can reach the locally attached networks on R1. R2 is running OSPF and has R3 as it’s directly connected neighbour; it is also running iBGP and peering with R3 as well. Default routing policies are used, unless otherwise configured. Lastly, R2 is configured in AS64501.

R3 is running OSPF and has R2 as it’s directly connected neighbour; it is also running iBGP and peering with R2. R3 is configured in AS64501. Lastly, it’s peering with ISP1 and ISP2 routers via eBGP. The default route points to ISP1

ISP1 & ISP2 routers will  receive aggregate routes from R3


CONFIGURATION

The objective here is to set a conditional default route pointing to ISP2 instead; this should only happen when the 85.85.85.85/32 route exists in the routing table on R3.

Since the preference of the aggregate default route is 130, I have explicitly increased the preference of the existing default static route to 150 so it’s less preferred (lower is better!).

set routing-options static route 0.0.0.0/0 next-hop 10.0.45.1
set routing-options static route 0.0.0.0/0 preference 150

Next I configured the policy and the generate default route 0.0.0.0/0:

set policy-options policy-statement cond-adv term match_route from route-filter 85.85.85.85/32 exact
set policy-options policy-statement cond-adv term match_route then accept
set policy-options policy-statement cond-adv then reject

set routing-options generate route 0.0.0.0/0 policy cond-adv

NOTICE through the routing policy cond-adv we actually change set which route(s) to be considered as contributing routes!

If there is a match against the host route 85.85.85.85/32, it is then accepted as contributing route and as a result, the next-hop will be set towards ISP2 router; otherwise there will be no valid contributing route.

In order to test, since the host route is configured on the loopback interface on ISP2 router, to stop advertising it I’ll just disable the interface.

Below is an excerpt of the routing tables with the aggregate accepted and with the aggregate rejected:


USEFUL SHOW COMMANDS

show route <aggRoute> [detail | extensive]

show interface route protocol aggregate

Thank you,

Rafael A. Couto Cabral • LinkedIn Profile
Cisco​ | F5 | VMware Certified • PRINCE2 Practitioner

Related Post

Comments are closed.