Junos Generated Routes
Topology#
graph LR
net1(LAN1_172.17.99.0/24)
net1 <--> R1
R1 <--> |WAN1_10.10.10.8/30|R4
Configuration and Interpretations#
Desired outcome: I want to configure a generated route on R1 for the prefix 172.17.99.0. Currently, the prefix 172.17.99.0/24 is directly attached to ge-0/0/6. I want to make R1 advertise the generated route 172.17.96.0/19 toward its BGP neighbor R4 only when R1 receives the BGP route 10.22.1.0/26 from R4 (which is configured as an aggregate route on R4) and successfully imports it from BGP into inet.0. On R1, at the moment there is only one contributing route for the generated route, which is 17.17.99.0/24.
In alignment with the Juniper courseware, I created:
- a routing option that contains the generated route. The configuration uses a similar CLI structure as with an aggregated route.
root@R1# show routing-options generate
defaults {
preference 131;
}
route 172.17.96.0/19;
[edit]
root@R1#
- a first routing policy called
TriggerOfGenRtto match the triggering route (10.22.1.0/26; the aggregate route configured on R4),
root@R1# show policy-options policy-statement TriggerOfGenRt
term Term1 {
from {
protocol bgp;
route-filter 10.22.1.0/26 exact;
}
then accept;
}
term Term2 {
then reject;
}
[edit]
root@R1#
- a second routing policy called
ExportGenRt_RPolto match the generated route.
root@R1# show policy-statement ExportGenRt_RPol
term term1 {
from {
protocol aggregate;
route-filter 172.17.96.0/19 exact;
}
then accept;
}
term term2 {
then reject;
}
[edit policy-options]
root@R1#
According to juniper courseware, I must reference the routing policy ‘TriggerOfGenRt’ in the routing option of the generated route:
[edit routing-options]
root@R1# set generate route 172.17.96.0/19 policy TriggerOfGenRt
[edit routing-options]
root@R1# show generate
defaults {
preference 131;
}
route 172.17.96.0/19 policy TriggerOfGenRt;
[edit routing-options]
root@R1# show
rib inet.0 {
static {
route 0.0.0.0/0 next-hop 172.17.81.1;
}
}
autonomous-system 17;
static {
route 10.22.1.32/27 {
next-hop 10.22.1.4;
resolve;
preference 12;
}
}
generate {
defaults {
preference 131;
}
route 172.17.96.0/19 policy TriggerOfGenRt;
}
[edit routing-options]
root@R1#
I removed the redundant routing policy from the export list of the BGP group and inserted the routing policy that references the generated route:
root@R1# show protocols bgp
group extGrp-79 {
type external;
export DirectroutesAccept;
peer-as 79;
neighbor 10.10.7.2;
}
group extGrp-22 {
type external;
import ModifyBGPattr;
export [ PREPEND-EXPORT LAN172.17.99 ];
peer-as 22;
neighbor 10.10.10.2;
neighbor 10.10.10.10;
}
root@R1# show policy-options policy-statement LAN172.17.99
term 1 {
from {
protocol direct;
prefix-list 99Network;
}
then accept;
}
[edit]
root@R1# delete protocols bgp group extGrp-22 export LAN172.17.99
[edit]
root@R1# set protocols bgp group extGrp-22 export ExportGenRt_RPol
[edit]
root@R1# show protocols bgp group extGrp-22
type external;
import ModifyBGPattr;
export [ PREPEND-EXPORT ExportGenRt_RPol ];
peer-as 22;
neighbor 10.10.10.2;
neighbor 10.10.10.10;
[edit]
root@R1#
But I do not see any generated route in the local RIB:
root@R1> show route 172.17.96.0/19 exact detail
inet.0: 17 destinations, 17 routes (14 active, 0 holddown, 3 hidden)
root@R1>
root@R1>
I checked which routes R1 is sending into BGP:
root@R1> show route advertising-protocol bgp 10.10.10.10
inet.0: 17 destinations, 17 routes (14 active, 0 holddown, 3 hidden)
Prefix Nexthop MED Lclpref AS path
* 1.1.1.1/32 Self 17 17 17 [17] I
* 172.17.99.0/24 Self 17 17 17 [17] I
root@R1>
This is not the desired outcome. I must check which routing policy is exporting 172.17.99.0/24 from RIB into BGP:
root@R1> show configuration protocols bgp
group extGrp-79 {
type external;
export DirectroutesAccept;
peer-as 79;
neighbor 10.10.7.2;
}
group extGrp-22 {
type external;
import ModifyBGPattr;
export [ PREPEND-EXPORT ExportGenRt_RPol ];
peer-as 22;
neighbor 10.10.10.2;
neighbor 10.10.10.10;
}
root@R1> show config policy-options policy-statement PREPEND-EXPORT
term 1 {
from {
protocol direct;
route-filter 1.1.1.1/32 exact;
}
then {
as-path-prepend "17 17 17";
accept;
}
}
term 2 {
from {
protocol direct;
route-filter 172.17.99.0/24 exact;
}
then {
as-path-prepend "17 17 17";
accept;
}
}
root@R1>
So I modified the routing policy PREPEND-EXPORT to not include the route 172.17.99.0/24 because exporting that route from RIB into BGP breaks the purpose of the generated route:
root@R1> ...cy-options policy-statement PREPEND-EXPORT
term 1 {
from {
protocol direct;
route-filter 1.1.1.1/32 exact;
}
then {
as-path-prepend "17 17 17";
accept;
}
}
root@R1>
root@R1> show configuration protocols bgp group extGrp-22
type external;
import ModifyBGPattr;
export [ PREPEND-EXPORT ExportGenRt_RPol ];
peer-as 22;
neighbor 10.10.10.2;
neighbor 10.10.10.10;
root@R1>
Still no success. I checked the hidden routes:
root@R1> show route hidden | find 172.17.96.0
172.17.96.0/19 [Aggregate] 2d 00:24:33
Reject
inet6.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
root@R1>
I assume that the generated route ‘sees’ no active contributing routes. There is probably a mistake in my configuration logic because I am sure that the contributing route is active in the RIB.
Update: It appeared to me that the policy option I configured for the routing option was incorrect; That line should contain an active contributing route, not the route from R4. However, currently the 10.22.1.0/26 from R4 is not a more-specific match to the generated route 172.17.96.0/19 in the lab.
So I downgrade the difficulty of this small lab until I upskill more in Junos routing logic.
New setup: R1 must advertise a generated route in the form of a default route 0/0 to R4, if it receives from R4 the route 10.22.1.0/26.
This means that I am going to attach the routing policy ‘TriggerOfGenRt’ to the routing option of the new generated route 0/0.
[edit]
root@R1# show policy-options policy-statement TriggerOfGenRt
term Term1 {
from {
protocol bgp;
route-filter 10.22.1.0/26 exact;
}
then accept;
}
term Term2 {
then reject;
}
[edit]
root@R1#
I started by deleting the previous generated route:
root@R1# edit routing-options
[edit routing-options]
root@R1# delete generate route 172.17.96.0/19
I set the default route instead and reference the routing policy ‘TriggerOfGenRt’ in the generated route config. The 10.22.1.0/26 prefix is numerically a more-specific match of the 0/0 prefix.
[edit routing-options]
root@R1# set generate route 0/0 policy TriggerOfGenRt
[edit routing-options]
root@R1# top
[edit]
root@R1# show routing-options generate
defaults {
preference 131;
}
route 0.0.0.0/0 policy TriggerOfGenRt;
[edit]
root@R1#
I adapted the routing policy that crafts the match of the default route:
[edit ]
root@R1# show policy-options policy-statement ExportGenRt_RPol
term term1 {
from {
protocol aggregate;
route-filter 0.0.0.0/0 exact;
}
then accept;
}
term term2 {
then reject;
}
I verify the correct implementation of the routing policy in the export direction to BGP:
[edit]
root@R1# show protocols bgp group extGrp-22
type external;
import ModifyBGPattr;
export [ PREPEND-EXPORT ExportGenRt_RPol ];
peer-as 22;
neighbor 10.10.10.2;
neighbor 10.10.10.10;
[edit]
root@R1#
root@R1# commit and-quit
commit complete
Exiting configuration mode
I verify the existence of the generated route locally on R1:
root@R1> show route 0.0.0.0/0 exact detail
inet.0: 16 destinations, 17 routes (14 active, 0 holddown, 2 hidden)
0.0.0.0/0 (2 entries, 1 announced)
*Static Preference: 5
Next hop type: Router, Next hop index: 351
Address: 0x77c6384
Next-hop reference count: 3, Next-hop session id: 0
Kernel Table Id: 0
Next hop: 172.17.81.1 via fxp0.0, selected
Session Id: 0
State: <Active Int Ext>
Local AS: 17
Age: 3d 0:50:59
Validation State: unverified
Task: RT
Announcement bits (2): 0-KRT 2-Resolve tree 1
AS path: I
Thread: junos-main
Aggregate Preference: 131
Next hop type: Router, Next hop index: 595
Address: 0x77c6934
Next-hop reference count: 10, Next-hop session id: 320
Kernel Table Id: 0
Next hop: 10.10.10.10 via ge-0/0/4.0, selected
Session Id: 320
State: <Int Ext Changed>
Inactive reason: Route Preference
Local AS: 17
Age: 14
Validation State: unverified
Task: Aggregate
AS path: I
Flags: Generate Depth: 0 Active
Contributing Routes (1):
10.22.1.0/26 proto BGP
Thread: junos-main
root@R1>
The generated route seems inactive in the RIB, with an inactive reason pointing to route preference; A static route with a better route preference is already configured. That explains why the generated route is not advertised in BGP:
root@R1> show route advertising-protocol bgp 10.10.10.10
inet.0: 16 destinations, 17 routes (14 active, 0 holddown, 2 hidden)
Prefix Nexthop MED Lclpref AS path
* 1.1.1.1/32 Self 17 17 17 [17] I
root@R1>
I modify the route preference of the generated route. I can either modify the defaults section or the preference of the specific generated route 0/0 itself. I choose to do the former because I have configured only one generated route.
[edit]
root@R1# show routing-options generate
defaults {
preference 4;
}
route 0.0.0.0/0 policy TriggerOfGenRt;
[edit]
root@R1#
The generated route is now selected as active in the inet.0 RIB; Notice that Junos identifies it as an aggregate route in the CLI:
root@R1> show route 0/0
inet.0: 16 destinations, 17 routes (14 active, 0 holddown, 2 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Aggregate/4] 00:00:04
> to 10.10.10.10 via ge-0/0/4.0
[Static/5] 3d 22:41:56
> to 172.17.81.1 via fxp0.0
1.1.1.1/32 *[Direct/0] 3d 22:41:56
> via lo0.0
10.10.7.0/30 *[Direct/0] 3d 22:41:37
> via ge-0/0/5.0
10.10.7.1/32 *[Local/0] 3d 22:41:37
Local via ge-0/0/5.0
10.10.10.0/30 *[Direct/0] 3d 22:41:37
> via ge-0/0/2.0
10.10.10.1/32 *[Local/0] 3d 22:41:37
Local via ge-0/0/2.0
10.10.10.8/30 *[Direct/0] 3d 22:41:37
> via ge-0/0/4.0
10.10.10.9/32 *[Local/0] 3d 22:41:37
Local via ge-0/0/4.0
10.22.1.0/26 *[BGP/170] 3d 22:41:25, localpref 200
AS path: 22 I, validation-state: unverified
> to 10.10.10.10 via ge-0/0/4.0
10.22.1.32/27 *[Static/12] 3d 22:41:25, metric2 0
> to 10.10.10.10 via ge-0/0/4.0
172.17.81.0/24 *[Direct/0] 3d 22:41:56
> via fxp0.0
172.17.81.42/32 *[Local/0] 3d 22:41:56
Local via fxp0.0
172.17.99.0/24 *[Direct/0] 3d 22:41:37
> via ge-0/0/6.0
172.17.99.69/32 *[Local/0] 3d 22:41:37
Local via ge-0/0/6.0
root@R1>
It is no longer hidden:
root@R1> show route hidden
inet.0: 16 destinations, 17 routes (14 active, 0 holddown, 2 hidden)
+ = Active Route, - = Last Active, * = Both
4.4.4.4/32 [BGP ] 3d 22:45:26, localpref 100
AS path: 22 I, validation-state: unverified
> to 10.10.10.10 via ge-0/0/4.0
10.22.1.0/27 [BGP ] 3d 22:45:35, localpref 100
AS path: 22 I, validation-state: unverified
> to 10.10.10.2 via ge-0/0/2.0
inet6.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
root@R1>
I verify that the generated route 0/0 takes the next hop value of its contributing route, the latter being 10.22.1.0/26:
root@R1> show route 10.22.1.0/26 exact
inet.0: 16 destinations, 17 routes (14 active, 0 holddown, 2 hidden)
+ = Active Route, - = Last Active, * = Both
10.22.1.0/26 *[BGP/170] 3d 22:46:54, localpref 200
AS path: 22 I, validation-state: unverified
> to 10.10.10.10 via ge-0/0/4.0
root@R1>
I expect to see the next hop value of ‘10.10.10.10’ as a next hop for the generated route too. This is confirmed in the CLI output:
root@R1> show route 0/0 exact detail
inet.0: 16 destinations, 17 routes (14 active, 0 holddown, 2 hidden)
0.0.0.0/0 (2 entries, 1 announced)
*Aggregate Preference: 4
Next hop type: Router, Next hop index: 595
Address: 0x77c6934
Next-hop reference count: 11, Next-hop session id: 320
Kernel Table Id: 0
Next hop: 10.10.10.10 via ge-0/0/4.0, selected
Session Id: 320
State: <Active Int Ext>
Local AS: 17
Age: 6:16
Validation State: unverified
Task: Aggregate
Announcement bits (3): 0-KRT 2-Resolve tree 1 4-BGP_RT_Background
AS path: I
Flags: Generate Depth: 0 Active
Contributing Routes (1):
10.22.1.0/26 proto BGP
Thread: junos-main
Static Preference: 5
Next hop type: Router, Next hop index: 351
Address: 0x77c6384
Next-hop reference count: 2, Next-hop session id: 0
Kernel Table Id: 0
Next hop: 172.17.81.1 via fxp0.0, selected
Session Id: 0
State: <Int Ext>
Inactive reason: Route Preference
Local AS: 17
Age: 3d 22:48:08
Validation State: unverified
Task: RT
AS path: I
Thread: junos-main
root@R1>
R1 is advertising the generated route as a BGP route to R4:
root@R1> show route advertising-protocol bgp 10.10.10.10
inet.0: 16 destinations, 17 routes (14 active, 0 holddown, 2 hidden)
Prefix Nexthop MED Lclpref AS path
* 0.0.0.0/0 10.10.10.10 I
* 1.1.1.1/32 Self 17 17 17 [17] I
root@R1>
From a routing perspective, the results have little practical use, since the generated route has a proven next hop of R4’s WAN interface and the latter receives that generated route from R1. The following output demonstrates whether the route, received in BGP is installed in R4’s inet.0 RIB:
root@R4> show route receive-protocol bgp 10.10.10.9
inet.0: 14 destinations, 16 routes (14 active, 0 holddown, 1 hidden)
Prefix Nexthop MED Lclpref AS path
* 1.1.1.1/32 10.10.10.9 17 17 17 17 I
inet6.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
root@R4> show route hidden
inet.0: 14 destinations, 16 routes (14 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 [BGP ] 00:01:07, localpref 100, from 10.10.10.9
AS path: 17 I, validation-state: unverified
> to 10.10.10.10 via ge-0/0/1.0
inet6.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
root@R4>
And Junos describes the reason as ‘unusable path’:
root@R4> show route hidden 0/0 exact detail
inet.0: 14 destinations, 16 routes (14 active, 0 holddown, 1 hidden)
0.0.0.0/0 (2 entries, 1 announced)
BGP /-101
Next hop type: Router, Next hop index: 0
Address: 0x77c6934
Next-hop reference count: 1, Next-hop session id: 0
Kernel Table Id: 0
Source: 10.10.10.9
Next hop: 10.10.10.10 via ge-0/0/1.0, selected
Session Id: 0
State: <Hidden Ext Changed>
Inactive reason: Unusable path
Local AS: 22 Peer AS: 17
Age: 4:36
Validation State: unverified
Task: BGP_17.10.10.10.9
AS path: 17 I
Localpref: 100
Router ID: 1.1.1.1
Hidden reason: Protocol nexthop is local
Thread: junos-main
root@R4>
The purpose however of this micro lab is to demonstrate the logic used by Junos when the design goal is to conditionally propagate a default route in the form of a generated route toward an eBGP neighbor.
#LessonLearned An active generated route is displayed as being an aggregate route in the RIB.
#LessonLearned In the configuration of the routing policy that will match on the generated route, the protocol type of a generated route is the same as of an aggregate route in Junos: I use the same option aggregate for both protocol types.
Open Topics#
#TBC Verify that there is no visible difference in CLI output between an aggregate route and a generated route. #TBC Verify that among two or more contributing routes, the one with the best preference (i.e. lowest numerical value) becomes the primary contributing route. #TBC Verify that among two or more contributing routes with identical preferences, the one with lowest numerical route values becomes the primary contributing route. #TBC Verify that a generated route gets its next hop value from its main contributing route. #TBC Contrast aggregated route with route summarization in Cisco for each of the assumptions. #TBC Contrast the concept of generated routes with Cisco IP LA tracking of a static route.