Static, Aggregate and Generate routes at JunOS
The more you get to know Juniper hardware, the more you fall in love with this hardware and JunOS operating system. Today we will talk about Static, Aggregate and Generate routes. There are articles in English on this topic (I didn’t even see any translations in Russian), so I decided to write my own article. I hope to help some novice engineer.
So, I'll start. All three types of routes listed above are inherently static routes and are defined in the junos configuration in the hierarchy of edit routing-options.
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 can be seen from the output, we need to get to the network 10.0.0.0/30 - we prescribe a static route and specify next hop. Packet routing over an IP network works on the principle of per-hop behavior (PHB), that is, each router itself determines where to send a packet based on the existing routing table (we are not considering source routing now). As next hop there should be a router, which will have a route to the specified network (it can also be static, it doesn’t matter), otherwise, the packet will simply be dropped by this router (with or without an ICMP message sent) static routes, so go ahead.
Aggregate route. In essence, this is the same static route, only next hop or reject or discard, that is, this route cannot be used to transmit traffic (except when traffic is intentionally wrapped in discard). The question is - 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 still change next-hop to itself (for ebgp by default, for ibgp you have to make a policy for next-hop self).
Here is the Aggregate route in the JunOS configuration:
With the help of this policy: aggregate-contribute-routes, we set the contribute route (Contribute) - in essence, this is a more specific prefix, which aggregates into a less specific prefix:
Aggregate route will be announced as long as it has at least one available contribute route. The following shows show route with the above configuration. Next-hop in this case reject.
This is how it will be transmitted to the bgp feast:
Now it remains to understand the nature of the generate route. Generate route is essentially the same aggregate route, but with a real next-hop, which is taken from the contribute route:
If the policy specifies two or more prefixes, then the router selects the next-hop from the specified contribute route, acting according to the following algorithm:
1. The route received from the protocol with the lowest protocol preference
2. The smallest route out of all, for example, from 192.168.1.0/24, 10.0.0.0/8 and 5.0.0.0/22 is the least.
3. If the first two conditions did not reveal the best route, then the route with the smallest long prefix is chosen.
An example of the use of generate route is the default route announced by the provider to the client, or 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 output shows that the route has a real next-hop.
Note: generate route can have next-hop discard if asked by the administrator. In this case, generate route will be similar to aggregate route. But for generate route can not be set 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 (as opposed to static, which has preference 5):
Also, when creating policies (for example, for export) and generate and aggregate route are denoted as protocol aggregate.
Thanks for attention!
So, I'll start. All three types of routes listed above are inherently static routes and are defined in the junos configuration in the hierarchy of edit routing-options.
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 can be seen from the output, we need to get to the network 10.0.0.0/30 - we prescribe a static route and specify next hop. Packet routing over an IP network works on the principle of per-hop behavior (PHB), that is, each router itself determines where to send a packet based on the existing routing table (we are not considering source routing now). As next hop there should be a router, which will have a route to the specified network (it can also be static, it doesn’t matter), otherwise, the packet will simply be dropped by this router (with or without an ICMP message sent) static routes, so go ahead.
Aggregate route. In essence, this is the same static route, only next hop or reject or discard, that is, this route cannot be used to transmit traffic (except when traffic is intentionally wrapped in discard). The question is - 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 still change next-hop to itself (for ebgp by default, for ibgp you have to make a policy for next-hop self).
Here is the Aggregate route in the JunOS configuration:
routing-options { aggregate { route 10.0.0.0/8 policy aggregate-contribute-routes; } With the help of this policy: aggregate-contribute-routes, we set the contribute route (Contribute) - in essence, this is a more specific prefix, which aggregates into a less specific prefix:
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 available contribute route. The following shows 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 This is how it will be transmitted to the bgp feast:
[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. Generate route is essentially the same aggregate route, but with a real next-hop, which 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 the policy specifies two or more prefixes, then the router selects the next-hop from the specified contribute route, acting according to the following algorithm:
1. The route received from the protocol with the lowest protocol preference
2. The smallest route out of all, for example, from 192.168.1.0/24, 10.0.0.0/8 and 5.0.0.0/22 is the least.
3. If the first two conditions did not reveal the best route, then the route with the smallest long prefix is chosen.
An example of the use of generate route is the default route announced by the provider to the client, or 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 output 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 can have next-hop discard if asked by the administrator. In this case, generate route will be similar to aggregate route. But for generate route can not be set 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 (as opposed to static, which has preference 5):
10.0.0.0/8 *[Aggregate/130] 00:30:20 Also, when creating policies (for example, for export) and generate and aggregate route are denoted as protocol aggregate.
Thanks for attention!
Source: https://habr.com/ru/post/274873/
All Articles