January 11, 2016 at 15:58Static, Aggregate, and Generate routes on JunOS
The more you become familiar with Juniper hardware, the more you fall in love with this hardware and the JunOS operating system. Today we will talk about Static, Aggregate and Generate routes. There are articles on this subject in English (I have not even seen translations in Russian), so I decided to write my article. I hope to help some novice engineer.
So, I will begin. All three types of routes listed above are inherently static routes and are specified in the junos configuration in the edit routing-options hierarchy.
So static route. Any network engineer knows what it is. We need to get into some kind of network, but there is no possibility (or desire) to use dynamic routing protocols, the output is static. Here is an example of a static route in juniper:
As you can see from the output, we need to get to the network 10.0.0.0/30 - we prescribe a static route and indicate next hop. Packet routing over an IP network works by the principle of per-hop behavior (PHB), that is, each router itself determines where to send the packet based on the existing routing table (we do not consider source routing now). The next hop should be a router that has a route to the specified network (it can also be static, it doesn’t matter), otherwise, the packet will be simply dropped by this router (with or without sending an ICMP message) I don’t see the point of writing more about static routes, so move on.
Aggregate route. In fact, this is the same static route, only the next hop or reject or discard, that is, this route cannot be used to transfer traffic (except when the traffic is intentionally wrapped in discard). The question arises - why do we need such a route ??? There are several uses for this route. The most common use is to combine several more specific prefixes into one less specific (for example, several / 27- / 28 into one / 24 or / 22) and transfer it to other bgp peers. Bgp will change next-hop for itself anyway (for ebgp by default, for ibgp you have to do a policy for next-hop self).
This is what the Aggregate route looks like in the JunOS configuration:
Using this policy: aggregate-contribute-routes, we set the contribute route (Contribute is a more specific prefix, which is aggregated into a less specific one):
Aggregate route will be announced as long as it has at least one contribute route available. Below is the output of show route with the above configuration. Next-hop in this case reject.
And so it will be passed to bgp-peer:
Now it remains to understand the nature of the generate route. The generate route is essentially the same aggregate route, but with a real next-hop that is taken from the contribute route:
If two or more prefixes are specified in the policy, then the router selects next-hop from the indicated contribute route, following the following algorithm:
1. The route received from the protocol with the least protocol preference
2. The smallest route of all, for example, from 192.168.1.0/24 , 10.0.0.0/8 and 5.0.0.0/22 the smallest is the last.
3. If the first two conditions did not reveal the best route, then the route with the shortest prefix length is selected.
An example of the use of generate route is the default route announced by the provider to the client, or the redistribution of external routes from BGP to IGP (instead of several hundred or thousands of routes, only one default route is generated):
Like aggregate, generate route is active as long as there is at least one contribute route. The conclusion shows that the route has a real next-hop.
Note: generate route may have next-hop discard, if asked by the administrator. In this case, generate route will be similar to aggregate route. But for generate route, you cannot specify next-hop reject.
One of the reasons that engineers often confuse or cannot understand the difference between generate and aggregate route is that in the routing table they have the same designation and preference equal to 130 (unlike static, which has preference 5):
Also, when compiling policies (for example, for export), both generate and aggregate route are designated as protocol aggregate.
Thanks for attention!
So, I will begin. All three types of routes listed above are inherently static routes and are specified in the junos configuration in the edit routing-options hierarchy.
So static route. Any network engineer knows what it is. We need to get into some kind of network, but there is no possibility (or desire) to use dynamic routing protocols, the output is static. Here is an example of a static route in juniper:
inet.0: 6 destinations, 13 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.0/30 *[Static/5] 19w3d 09:40:52
> to 10.0.10.10 via ge-1/3/2
As you can see from the output, we need to get to the network 10.0.0.0/30 - we prescribe a static route and indicate next hop. Packet routing over an IP network works by the principle of per-hop behavior (PHB), that is, each router itself determines where to send the packet based on the existing routing table (we do not consider source routing now). The next hop should be a router that has a route to the specified network (it can also be static, it doesn’t matter), otherwise, the packet will be simply dropped by this router (with or without sending an ICMP message) I don’t see the point of writing more about static routes, so move on.
Aggregate route. In fact, this is the same static route, only the next hop or reject or discard, that is, this route cannot be used to transfer traffic (except when the traffic is intentionally wrapped in discard). The question arises - why do we need such a route ??? There are several uses for this route. The most common use is to combine several more specific prefixes into one less specific (for example, several / 27- / 28 into one / 24 or / 22) and transfer it to other bgp peers. Bgp will change next-hop for itself anyway (for ebgp by default, for ibgp you have to do a policy for next-hop self).
This is what the Aggregate route looks like in the JunOS configuration:
routing-options {
aggregate {
route 10.0.0.0/8 policy aggregate-contribute-routes;
}
Using this policy: aggregate-contribute-routes, we set the contribute route (Contribute is a more specific prefix, which is aggregated into a less specific one):
policy-options {
prefix-list contribute-1 {
10.0.0.0/30; ## в данном примере это будет contribute route
10.0.1.0/30;
10.0.2.0/30;
10.1.1.1/32;
10.1.1.2/32;
10.1.1.3/32;
}
policy-statement aggregate-contribute-routes {
term 1 {
from {
prefix-list contribute-1;
}
then accept;
}
}
Aggregate route will be announced as long as it has at least one contribute route available. Below is the output of show route with the above configuration. Next-hop in this case reject.
inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1.0.0.0/30 *[Direct/0] 00:38:45
> via ge-0/0/2.0
1.0.0.2/32 *[Local/0] 00:38:45
Local via ge-0/0/2.0
10.0.0.0/8 *[Aggregate/130] 00:23:27
Reject ## next-hop равен reject
10.0.0.0/30 *[BGP/170] 00:31:03, MED 0, localpref 100
AS path: 200 ?
> to 1.0.0.1 via ge-0/0/2.0
10.0.1.0/30 *[BGP/170] 00:31:03, MED 0, localpref 100
AS path: 200 ?
> to 1.0.0.1 via ge-0/0/2.0
10.0.2.0/30 *[BGP/170] 00:31:03, MED 4500, localpref 100
AS path: 200 ?
> to 1.0.0.1 via ge-0/0/2.0
10.1.1.1/32 *[BGP/170] 00:31:03, MED 0, localpref 100
AS path: 200 ?
> to 1.0.0.1 via ge-0/0/2.0
10.1.1.2/32 *[BGP/170] 00:31:03, MED 4500, localpref 100
AS path: 200 ?
> to 1.0.0.1 via ge-0/0/2.0
10.1.1.3/32 *[BGP/170] 00:31:03, MED 4500, localpref 100
AS path: 200 ?
> to 1.0.0.1 via ge-0/0/2.0
And so it will be passed to bgp-peer:
[edit]
root# run show route advertising-protocol bgp 20.1.1.2
inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.0.0.0/8 Self 100 200 ?
Now it remains to understand the nature of the generate route. The generate route is essentially the same aggregate route, but with a real next-hop that is taken from the contribute route:
[edit routing-options]
root# show
generate {
route 10.0.0.0/8 policy aggregate-contribute-routes;
policy-options {
prefix-list contribute-1 {
10.0.0.0/30; ## в данном примере это будет contribute route
10.0.1.0/30;
10.0.2.0/30;
10.1.1.1/32;
10.1.1.2/32;
10.1.1.3/32;
}
policy-statement aggregate-contribute-routes {
term 1 {
from {
prefix-list contribute-1;
}
then accept;
}
}
If two or more prefixes are specified in the policy, then the router selects next-hop from the indicated contribute route, following the following algorithm:
1. The route received from the protocol with the least protocol preference
2. The smallest route of all, for example, from 192.168.1.0/24 , 10.0.0.0/8 and 5.0.0.0/22 the smallest is the last.
3. If the first two conditions did not reveal the best route, then the route with the shortest prefix length is selected.
An example of the use of generate route is the default route announced by the provider to the client, or the redistribution of external routes from BGP to IGP (instead of several hundred or thousands of routes, only one default route is generated):
R5#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
20.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
C 20.0.0.0/30 is directly connected, GigabitEthernet1/0
C 20.0.1.0/30 is directly connected, GigabitEthernet2/0
C 20.1.1.2/32 is directly connected, Loopback0
O 20.0.2.0/30 [110/2] via 20.0.1.2, 00:00:07, GigabitEthernet2/0
O 20.1.1.3/32 [110/2] via 20.0.1.2, 00:00:07, GigabitEthernet2/0
B 10.0.0.0/8 [200/0] via 20.1.1.1, 00:01:36 ## аггрегированный маршрут
Like aggregate, generate route is active as long as there is at least one contribute route. The conclusion shows that the route has a real next-hop.
inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1.0.0.0/30 *[Direct/0] 00:35:07
> via ge-0/0/2.0
1.0.0.2/32 *[Local/0] 00:35:07
Local via ge-0/0/2.0
10.0.0.0/8 *[Aggregate/130] 00:19:49
> to 1.0.0.1 via ge-0/0/2.0 ## реальный next-hop
10.0.0.0/30 *[BGP/170] 00:27:25, MED 0, localpref 100
AS path: 200 ?
> to 1.0.0.1 via ge-0/0/2.0
10.0.1.0/30 *[BGP/170] 00:27:25, MED 0, localpref 100
AS path: 200 ?
> to 1.0.0.1 via ge-0/0/2.0
10.0.2.0/30 *[BGP/170] 00:27:25, MED 4500, localpref 100
AS path: 200 ?
> to 1.0.0.1 via ge-0/0/2.0
10.1.1.1/32 *[BGP/170] 00:27:25, MED 0, localpref 100
AS path: 200 ?
> to 1.0.0.1 via ge-0/0/2.0
10.1.1.2/32 *[BGP/170] 00:27:25, MED 4500, localpref 100
AS path: 200 ?
> to 1.0.0.1 via ge-0/0/2.0
10.1.1.3/32 *[BGP/170] 00:27:25, MED 4500, localpref 100
AS path: 200 ?
> to 1.0.0.1 via ge-0/0/2.0
Note: generate route may have next-hop discard, if asked by the administrator. In this case, generate route will be similar to aggregate route. But for generate route, you cannot specify next-hop reject.
[edit]
root# show routing-options
generate {
route 10.0.0.0/8 {
policy aggregate-contribute-routes;
discard;
}
}
root# run show route
inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1.0.0.0/30 *[Direct/0] 00:45:38
> via ge-0/0/2.0
1.0.0.2/32 *[Local/0] 00:45:38
Local via ge-0/0/2.0
10.0.0.0/8 *[Aggregate/130] 00:30:20
Discard ## next-hop равен discard
One of the reasons that engineers often confuse or cannot understand the difference between generate and aggregate route is that in the routing table they have the same designation and preference equal to 130 (unlike static, which has preference 5):
10.0.0.0/8 *[Aggregate/130] 00:30:20
Also, when compiling policies (for example, for export), both generate and aggregate route are designated as protocol aggregate.
Thanks for attention!