The Junos 'generated route'

A generated route is made available as a route of last resort and is conditional on a contributing route existing in inet.0.  (Note: You can create generated routes in other tables by using 'rib inet.x' hierarchy.  This excludes IPv[46] multicast routing tables inet.1 and inet6.1)

As an example, picture the two routers below connected by a point-to-point link:

CUST: AS65421
fxp0.0 10.12.0.0/31
lo0.0 1.1.1.1


ISP: AS503
fxp0.0 10.12.0.1/31
lo0.0 2.2.2.2

BGP is set up between the two nodes as follows:

1. ISP advertises only lo0 to CUST

policy-statement BGP-CUST-EXPORT {
    from interface lo0.0;
    then accept;
}

2. ISP accepts only AS65421 originated prefixes:

policy-statement BGP-CUST-IMPORT {
    from as-path AS65421-ORIGIN;
    then accept;
}
as-path AS65421-ORIGIN "^65421$";

3. CUST sends all direct routes to ISP and does not filter any inbound prefixes:

policy-statement BGP-EXPORT {
    from protocol direct;
    then accept;
}


Here we have full connectivity between the two nodes, however the CUST AS has no external routes:

root@CUST> show route terse | match /   
* 1.1.1.1/32         D   0                       >lo0.0        
* 2.2.2.2/32         B 170        100            >10.12.0.1       503 I
* 10.12.0.0/31       D   0                       >fxp0.0       
* 10.12.0.0/32       L   0                        Local

We can verify that by checking for a route to Google DNS:

root@CUST> show route 8.8.8.8 


root@CUST> 

CUST is planning on adding a second upstream ISP for failover and is planing on offering upstream connectivity to future downstream peers.  To facilitate these business goals CUST decides to generate a default route based on connectivity to ISP's lo0 address (2.2.2.2/32).  The decide to create a 0/0 generated route as follows:

routing-options {
    generate {
        route 0.0.0.0/0;
    }
    autonomous-system 65421;
}

Once this change has been committed their routing table looks like this:

root@CUST> show route terse | match /    
* 0.0.0.0/0          A 130                       >10.12.0.1
* 1.1.1.1/32         D   0                       >lo0.0        
* 2.2.2.2/32         B 170        100            >10.12.0.1       503 I
* 10.12.0.0/31       D   0                       >fxp0.0       
* 10.12.0.0/32       L   0                        Local

Note the aggregate route for 0/0.  Further scrutiny shows that the BGP prefix 2.2.2.2/32 from ISP is the contributing route:

root@CUST> show route 0.0.0.0/0 exact extensive 


inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
0.0.0.0/0 (1 entry, 1 announced)
TSI:
KRT in-kernel 0.0.0.0/0 -> {10.12.0.1}
        *Aggregate Preference: 130
                Next hop type: Router, Next hop index: 541
                Next-hop reference count: 4
                Next hop: 10.12.0.1 via fxp0.0, selected
                State: <Active Int Ext>
                Local AS: 65421 
                Age: 8:53 
                Task: Aggregate
                Announcement bits (1): 0-KRT 
                AS path: I
                                Flags: Generate Depth: 0 Active
                Contributing Routes (1):
                 2.2.2.2/32 proto BGP

When the BGP advertisements from ISP are withdrawn, CUST loses their default route:

root@CUST> show route terse | match / 
* 1.1.1.1/32         D   0                       >lo0.0        
* 10.12.0.0/31       D   0                       >fxp0.0       
* 10.12.0.0/32       L   0                        Local

For now this meets the requirements of CUST, however here are some points to think on:

1. What happens if ISP loses their upstream connectivity?
2. When CUST adds another upstream connection how will they handle egress traffic?