Configuring Route Aggregation
Understanding Route Aggregation
The route aggregation methodology helps minimize the number of routing tables in an IP network by consolidating selected multiple routes into a single route advertisement. This approach is in contrast to non-aggregation routing, in which every routing table contains a unique entry for each route. The aggregation methodology does not help reduce the size of the routing-table on the router that does the aggregation. When you configure an export policy that only advertises the aggregate but not the contributing routes anymore, you then have the aggregation effect on the routers that receive updates.
An aggregate route becomes active when it has one or more contributing routes. A contributing route is an active
route that is a more specific match for the aggregate destination.
For example, for the aggregate destination 192.168.0.0/16, routes to 192.168.192.0/19 and 192.168.67.0/24 are contributing routes, but routes to 192.168.0.0./8 and 192.168.0.0/16 are not.
A route can only contribute to a single aggregate route. However,
an active aggregate route can recursively contribute to a less-specific
matching aggregate route. For example, an aggregate route to the destination 192.168.0.0/16 can contribute to an aggregate route to 192.168.0.0/13.
When an aggregate route becomes active, it is installed in the routing table with the following information:
Reject next hop—If a more-specific packet does not match a more-specific route, the packet is rejected and an ICMP unreachable message is sent to the packet’s originator.
Metric value as configured with the
aggregatestatement.Preference value that results from the policy filter on the primary contributor, if a filter is specified.
AS path as configured in the
aggregatestatement, if any. Otherwise, the path is computed by aggregating the paths of all contributing routes.Community as configured in the
aggregatestatement, if any is specified.Note:You can configure only one aggregate route for each destination prefix.
To configure aggregate routes in the default routing table (inet.0), include the aggregate statement:
aggregate { defaults { ... aggregate-options ... } route destination-prefix { policy policy-name; ... aggregate-options ... } }
To configure aggregate routes in one of the other routing tables,
or to explicitly configure aggregate routes in the default routing
table (inet.0), include the aggregate statement:
rib routing-table-name { aggregate { defaults { ... aggregate-options ... } route destination-prefix { policy policy-name; ... aggregate-options ... } } }
You cannot configure aggregate routes for the IPv4 multicast routing table (inet.1) nor the IPv6 multicast routing table (inet6.1).
The aggregate statement consists of two parts:
defaults—(Optional) Here you specify global aggregate route options. These are treated as global defaults and apply to all the aggregate routes you configure in theaggregatestatement.route—Here you configure individual aggregate routes. In this part of theaggregatestatement, you optionally can configure aggregate route options. These options apply to the individual destination only and override any options you configured in thedefaultspart of theaggregatestatement.
When you configure an individual aggregate route in the route part of the aggregate statement, specify the
destination of the route (in route destination-prefix) in one of the following ways:
network/mask-length, wherenetworkis the network portion of the IP address andmask-lengthis the destination prefix length.defaultif this is the default route to the destination. This is equivalent to specifying an IP address of0.0.0.0/0.
After you have configured aggregate routes, you can have a protocol advertise the routes by configuring a policy that is then exported by a routing protocol.
You can associate a routing policy when configuring an aggregate
route’s destination prefix in the routes part of
the aggregate statement. Doing so provides the equivalent
of an import routing policy filter for the destination prefix. That
is, each potential contributor to an aggregate route, along with any
aggregate options, is passed through the policy filter. The policy
then can accept or reject the route as a contributor to the aggregate
route and, if the contributor is accepted, the policy can modify the
default preferences.
The following algorithm is used to compare two aggregate contributing routes in order to determine which one is the primary or preferred contributor:
Compare the protocol’s
preferencesof the contributing routes. The lower the preference, the better the route. This is similar to the comparison that is done while determining the best route for the routing table.Compare the protocol’s
preferences2of the contributing routes. The lower preference2 value is better. If only one route haspreferences2, then this route is preferred.The preference values are the same. Proceed with a numerical comparison of the prefix values.
The primary contributor is the numerically smallest prefix value.
If the two prefixes are numerically equal, the primary contributor is the route that has the smallest prefix length value.
At this point, the two routes are the same. The primary contributor does not change. An additional next hop is available for the existing primary contributor.
A rejected contributor still can contribute to a less specific aggregate route. If you do not specify a policy filter, all candidate routes contribute to an aggregate route.
To associate a routing policy with an aggregate route, include
the policy statement when configuring the route:
aggregate (defaults | route) { policy policy-name; }
In the defaults and route parts of the aggregate statement, you can specify aggregate-options, which define additional information about aggregate routes
that is included with the route when it is installed in the routing
table. All aggregate options are optional. Aggregate options that
you specify in the defaults part of the aggregate statement are treated as global defaults and apply to all the aggregate
routes you configure in the aggregate statement. Aggregate
options that you specify in the route part of the aggregate statement override any global aggregate options and
apply to that destination only.
To configure aggregate route options, include one or more of
them in the defaults or route part of the aggregate statement:
[edit] routing-options { aggregate { (defaults | route) { (active | passive); as-path <as-path> <origin (egp | igp | incomplete)> <atomic-aggregate> <aggregator as-number in-address>; community [ community-ids ]; discard; (brief | full); (metric | metric2 | metric3 | metric4) metric <type type>; (preference | preference2 | color | color2) preference <type type>; tag metric type number; } } }
- Configuring a Metric Value for Aggregate Routes
- Configuring a Preference Value for Aggregate Routes
- Configuring the Next Hop for Aggregate Routes
- Associating BGP Communities with Aggregate Routes
- Associating AS Paths with Aggregate Routes
- Including AS Numbers in Aggregate Route Paths
- Configuring a Tag Value for Aggregate Routes
- Controlling Retention of Inactive Aggregate Routes in the Routing and Forwarding Tables
Configuring a Metric Value for Aggregate Routes
You can specify up to four metric values, starting with metric (for the first metric value) and continuing with metric2, metric3, and metric4 by including
one or more of the following statements:
aggregate (defaults | route) { (metric | metric2 | metric3 | metric4) metric <type type>; }
For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements.
In the type option, you can specify the type of route.
Configuring a Preference Value for Aggregate Routes
By default, aggregate routes have a preference value of 130. If the routing table contains a dynamic route to a destination that has a better (lower) preference value than this, the dynamic route is chosen as the active route and is installed in the forwarding table.
To modify the default preference value, specify a primary preference
value (preference). You also can specify secondary preference
value (preference2); and colors, which are even finer-grained
preference values (color and color2). To do
this, include one or more of the following statements:
aggregate (defaults | route) { (preference | preference2 | color | color2) preference <type type>; }
For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements.
The preference value can be a number in the range from 0 through 4,294,967,295 (232 – 1) with a lower number indicating a more preferred route. For more information about preference values, see Route Preferences Overview.
In the type option, you can specify the type of route.
Configuring the Next Hop for Aggregate Routes
By default, when aggregate routes are installed in the routing table, the next hop is configured as a reject route. That is, the packet is rejected and an ICMP unreachable message is sent to the packet’s originator.
When you configure an individual route in the route part of the aggregate statement, or when you configure
the defaults for aggregate routes, you can specify a discard next
hop. This means that if a more specific packet does not match a more
specific route, the packet is rejected and a reject route for this
destination is installed in the routing table, but ICMP unreachable
messages are not sent.
Being able to discard next hops allows you to originate a summary
route, which can be advertised through dynamic routing protocols,
and allows you to discard received traffic that does not match a more
specific route than the summary route. To discard next hops, include
the discard option:
discard;
For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.
Associating BGP Communities with Aggregate Routes
By default, no BGP community information is associated with
aggregate routes. To associate community information with the routes,
include the community option:
aggregate (defaults | route) { community [ community-ids ]; }
For a list of hierarchy levels at which you can include this
statement, see the statement summary section for this statement. community-value is the community identifier
and can be a number in the range from 0 through 65,535.
community-ids is one or more
community identifiers for either communities or extended communities.
The format for community identifiers is:
as-number:community-value
as-number is the AS number and
can be a value in the range from 1 through 65,534.
You also can specify community-ids for communities as one of the following well-known community
names, which are defined in RFC 1997:
no-export—Routes containing this community name are not advertised outside a BGP confederation boundary.no-advertise—Routes containing this community name are not advertised to other BGP peers.no-export-subconfed—Routes containing this community name are not advertised to external BGP peers, including peers in other members’ ASs inside a BGP confederation.
You can explicitly exclude BGP community information with an
aggregate route using the none option. Include none when configuring an individual route in the route portion
of the aggregate statement to override a community option specified in the defaults portion of the statement.
Extended community attributes are not supported at the [edit routing-options] hierarchy level. You must configure
extended communities at the [edit policy-options] hierarchy
level. For information about configuring extended communities information,
see the “Configuring the Extended Communities Attribute”
section in the Routing Policies, Firewall Filters, and Traffic Policers User Guide. For information about configuring
4-byte AS numbers and extended communities, see Using
4-Byte Autonomous System Numbers in BGP Networks.
Associating AS Paths with Aggregate Routes
By default, the AS path for aggregate routes is built from the
component routes. To manually specify the AS path and associate AS
path information with the routes, include the as-path option:
aggregate (defaults | route) { as-path <as-path> <origin (egp | igp | incomplete)> <atomic-aggregate> <aggregator as-number in-address>; }
For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.
as-path is the AS path to include
with the route. It can include a combination of individual AS path
numbers and AS sets. Enclose sets in brackets ( [ ] ).
The first AS number in the path represents the AS immediately adjacent
to the local AS. Each subsequent number represents an AS that is progressively
farther from the local AS, heading toward the origin of the path.
In Junos OS Release 9.1 and later, the numeric AS range is extended to provide BGP support for 4-byte AS numbers, as defined in RFC 4893, BGP Support for Four-octet AS Number Space. For the AS number, you can configure a value from 1 through 4,294,967,295. All releases of Junos OS support 2-byte AS numbers. The 2-byte AS number range is 1 through 65,535 (this is a subset of the 4-byte range).
In Junos OS Release 9.2 and later, you can also configure a 4-byte AS number using the AS-dot notation format of two integer values joined by a period: <16-bit high-order value in decimal>.<16-bit low-order value in decimal>. For example, the 4-byte AS number of 65,546 in plain-number format is represented as 1.10 in the AS-dot notation format. You can specify a value in the range from 0.0 through 65535.65535 in AS-dot notation format.
You also can specify the AS path using the BGP origin attribute, which indicates the origin of the AS path information:
egp—Path information originated in another AS.igp—Path information originated within the local AS.incomplete—Path information was learned by some other means.
To attach the BGP ATOMIC_AGGREGATE path attribute
to the aggregate route, specify the atomic-aggregate option.
This path attribute indicates that the local system selected a less
specific route rather than a more specific route.
To attach the BGP AGGREGATOR path attribute to the
aggregate route, specify the aggregator option. When using
this option, you must specify the last AS number that formed the aggregate
route (encoded as two octets), followed by the IP address of the BGP
system that formed the aggregate route.
Starting with Junos OS 13.2R1, a BGP route is hidden when the AS path of an aggregate route—built from contributing routes— is more than half of the maximum BGP packet size (4096 bytes). Such AS paths have the OverflowASPathSize flag set for them. If you would like to leak such a BGP route, whose AS path length can overflow, we recommend to add the AS path statically in the default route configuration. For example:
[edit routing-instances instance-name routing options] user@host# set aggregate route 0.0.0.0/0 as-path path 1267
Including AS Numbers in Aggregate Route Paths
By default, all AS numbers from all contributing paths are included
in the aggregate route’s path. To include only the longest common
leading sequences from the contributing AS paths, include the brief option when configuring the route. If doing this results
in AS numbers being omitted from the aggregate route, the BGP ATOMIC_ATTRIBUTE path attribute is included with the aggregate
route.
aggregate (defaults | route) { brief; }
To explicitly have all AS numbers from all contributing paths
be included in the aggregate route’s path, include the full option when configuring routes. Include this option when
configuring an individual route in the route portion of
the aggregate statement to override a retain option specified in the defaults portion of the statement.
aggregate (defaults | route) { full; }
For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements.
Configuring a Tag Value for Aggregate Routes
By default, no tag values are associated with aggregate routes.
You can specify a tag value by including the tag option:
aggregate (defaults | route) { tag metric type number; }
For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.
Controlling Retention of Inactive Aggregate Routes in the Routing and Forwarding Tables
Static routes are only removed from the routing table if the
next hop becomes unreachable, which happens if there are no contributing
routes. To have an aggregate route remain continually installed in
the routing and forwarding tables, include the passive option
when configuring the route:
aggregate (defaults | route) { passive; }
Routes that have been configured to remain continually installed
in the routing and forwarding tables are marked with reject next hops when they are inactive.
To explicitly remove aggregate routes when they become inactive,
include the active option when configuring routes. Include
this option when configuring an individual route in the route portion of the aggregate statement to override a passive option specified in the defaults portion of the statement.
aggregate (defaults | route) { active; }
Example: Summarizing Static Routes Through Route Aggregation
This example shows how to summarize routes by configuring aggregate routes.
Requirements
No special configuration beyond device initialization is required before configuring this example.
Overview
In this example:
- Device R1 is connected to customer networks 10.200.1.0/24 and
10.200.2.0/24.
For demonstration purposes, these routes are represented in this example as loopback interfaces on Device R1.
- Device R1 has a static default route to reach the ISP network (10.0.45.0).
- Device R2 has static routes configured to reach Device R1’s customer networks (10.200.1.0/24 and 10.200.2.0/24).
- Device R2 also has a routing policy configured to advertise all static routes to its neighbor, Device R3.
- When Device R3 sends information about these routes (10.200.1.0/24 and 10.200.2.0/24) to Device ISP, the information is summarized as a single aggregate route (10.200.0.0/16).
- Device R2 and Device R3 share an IBGP session and have OSPF as the IGP.
- Device ISP injects a default route into AS 64501.
This example shows the configuration for all of the devices and the step-by-step configuration on Device R3.
Configuration
CLI Quick Configuration
To quickly configure this example, copy the
following commands, paste them into a text file, remove any line breaks,
change any details necessary to match your network configuration,
and then copy and paste the commands into the CLI at the [edit] hierarchy level.
Device R1
set interfaces ge-0/0/0 description R1-to-R2 set interfaces ge-0/0/0 unit 0 family inet address 10.0.0.1/30 set interfaces lo0 unit 0 family inet address 10.200.1.1/24 set interfaces lo0 unit 0 family inet address 10.200.2.2/24 set routing-options static route 0.0.0.0/0 next-hop 10.0.0.2
Device R2
set interfaces ge-0/0/0 description R2-to-R1 set interfaces ge-0/0/0 unit 0 family inet address 10.0.0.2/30 set interfaces ge-0/0/1 description R2-to-R3 set interfaces ge-0/0/1 unit 0 family inet address 10.0.2.2/30 set interfaces lo0 unit 0 family inet address 192.168.100.2/32 set policy-options policy-statement send-customer-routes from protocol static set policy-options policy-statement send-customer-routes then accept set protocols bgp group internal type internal set protocols bgp group internal local-address 192.168.100.2 set protocols bgp group internal export send-customer-routes set protocols bgp group internal neighbor 192.168.100.3 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive set routing-options autonomous-system 64501 set routing-options static route 10.200.1.0/24 next-hop 10.0.0.1 set routing-options static route 10.200.2.0/24 next-hop 10.0.0.1
Device R3
set interfaces ge-0/0/1 description R3-to-R2 set interfaces ge-0/0/1 unit 0 family inet address 10.0.2.1/30 set interfaces ge-0/0/2 description R3-to-ISP set interfaces ge-0/0/2 unit 0 family inet address 10.0.45.2/30 set interfaces lo0 unit 0 family inet address 192.168.100.3/32 set policy-options policy-statement next-hop-self term 1 from protocol bgp set policy-options policy-statement next-hop-self term 1 then next-hop self set policy-options policy-statement next-hop-self term 1 then accept set policy-options policy-statement send-aggregate term 1 from protocol aggregate set policy-options policy-statement send-aggregate term 1 then accept set policy-options policy-statement send-aggregate term suppress-specific-routes from route-filter 10.200.0.0/16 longer set policy-options policy-statement send-aggregate term suppress-specific-routes then reject set protocols bgp group external type external set protocols bgp group external export send-aggregate set protocols bgp group external peer-as 64502 set protocols bgp group external neighbor 10.0.45.1 set protocols bgp group internal type internal set protocols bgp group internal local-address 192.168.100.3 set protocols bgp group internal export next-hop-self set protocols bgp group internal neighbor 192.168.100.2 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive set routing-options autonomous-system 64501 set routing-options aggregate route 10.200.0.0/16
Device ISP
set interfaces ge-0/0/2 description ISP-to-R3 set interfaces ge-0/0/2 unit 0 family inet address 10.0.45.1/30 set policy-options policy-statement advertise-default term 1 from route-filter 0.0.0.0/0 exact set policy-options policy-statement advertise-default term 1 then accept set protocols bgp group external type external set protocols bgp group external export advertise-default set protocols bgp group external peer-as 64501 set protocols bgp group external neighbor 10.0.45.2 set routing-options autonomous-system 64502 set routing-options static route 0.0.0.0/0 discard
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.
To configure Device R3:
-
Configure the device interfaces.
[edit interfaces] user@R3# set ge-0/0/1 description R3-to-R2 user@R3# set ge-0/0/1 unit 0 family inet address 10.0.2.1/30 user@R3# set ge-0/0/2 description R3-to-ISP user@R3# set ge-0/0/2 unit 0 family inet address 10.0.45.2/30 user@R3# set lo0 unit 0 family inet address 192.168.100.3/32
Configure the AS number.
[edit routing-options] user@R3# set autonomous-system 64501
-
Configure an EBGP session with the ISP device.
[edit protocols] user@R3# set bgp group external type external user@R3# set bgp group external peer-as 64502 user@R3# bgp group external neighbor 10.0.45.1
-
Configure an IBGP session with Device R2.
[edit protocols] user@R3# set bgp group internal type internal user@R3# set bgp group internal local-address 192.168.100.3 user@R3# set bgp group internal neighbor 192.168.100.2
-
Configure OSPF as the IGP.
[edit protocols] user@R3# set ospf area 0.0.0.0 interface ge-0/0/1.0 user@R3# set ospf area 0.0.0.0 interface lo0.0 passive
-
Configure the aggregate route for the customer network routes.
[edit routing-options] user@R3# set aggregate route 10.200.0.0/16
-
Configure a routing policy to advertise the aggregate route.
The first term in this policy advertises the aggregate route. The second term prevents more specific routes from being advertised.
[edit policy-options] user@R3# set policy-statement send-aggregate term 1 from protocol aggregate user@R3# set policy-statement send-aggregate term 1 then accept user@R3# set policy-statement send-aggregate term suppress-specific-routes from route-filter 10.200.0.0/16 longer user@R3# set policy-statement send-aggregate term suppress-specific-routes then reject
-
Configure a routing policy to report Device R3 as the next hop as a result of participating in the EBGP session with Device ISP.
[edit policy-options] user@R3# set policy-statement next-hop-self term 1 from protocol bgp user@R3# set policy-statement next-hop-self term 1 then next-hop self user@R3# set policy-statement next-hop-self term 1 then accept
-
Apply the aggregate route policy to the EBGP session with Device ISP.
[edit protocols] user@R3# set bgp group external export send-aggregate
-
Apply the next-hop-self policy to the IBGP session with Device R2.
[edit protocols] user@R3# set bgp group internal export next-hop-self
If you are done configuring the device, commit the configuration.
[edit] user@R3# commit
Results
Confirm your configuration by issuing the show
interfaces, show protocols, show policy-options, and show routing-options commands. If the output does
not display the intended configuration, repeat the instructions in
this example to correct the configuration.
user@R3# show interfaces
ge-0/0/1 {
description R3-to-R2;
unit 0 {
family inet {
address 10.0.2.1/30;
}
}
}
ge-0/0/2 {
description R3-to-ISP;
unit 0 {
family inet {
address 10.0.45.2/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.100.3/32;
}
}
}
user@R3# show protocols
bgp {
group external {
type external;
export send-aggregate;
peer-as 64502;
neighbor 10.0.45.1;
}
group internal {
type internal;
local-address 192.168.100.3;
export next-hop-self;
neighbor 192.168.100.2;
}
}
ospf {
area 0.0.0.0 {
interface ge-0/0/1.0;
interface lo0.0 {
passive;
}
}
}
user@R3# show policy-options
policy-statement next-hop-self {
term 1 {
from protocol bgp;
then {
next-hop self;
accept;
}
}
}
policy-statement send-aggregate {
term 1 {
from protocol aggregate;
then accept;
}
term suppress-specific-routes {
from {
route-filter 10.200.0.0/16 longer;
}
then reject;
}
}
user@R3# show routing-options
autonomous-system 64501;
aggregate {
route 10.200.0.0/16;
}Verification
Confirm that the configuration is working properly.
- Verifying That Device R3 Has the Expected Routes
- Verifying That Device R3 Advertises the Aggregate Route to Device ISP
- Verifying End-to-End Connection
Verifying That Device R3 Has the Expected Routes
Purpose
Confirm that Device R3 has the advertised static routes from Device R2.
Action
user@R3>show route terse protocol bgp inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both A Destination P Prf Metric 1 Metric 2 Next hop AS path * 0.0.0.0/0 B 170 100 >10.0.45.1 64502 I * 10.200.1.0/24 B 170 100 >10.0.2.2 I * 10.200.2.0/24 B 170 100 >10.0.2.2 I
Meaning
The output shows that Device R3 has learned the static routes configured on Device R2 to reach Device R1’s customer networks (10.200.1.0/24 and 10.200.2.0/24) through IBGP peering.
Verifying That Device R3 Advertises the Aggregate Route to Device ISP
Purpose
Make sure that Device R3 does not send the specific static routes and only sends the summarized aggregate route.
Action
user@R3>show route advertising-protocol bgp 10.0.45.1 inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 10.200.0.0/16 Self I
Meaning
The output shows that Device R3 sends only the summarized route to Device ISP.
Verifying End-to-End Connection
Purpose
Confirm end-to-end connection from the customer network on Device R1 to Device ISP.
Action
user@R1>ping 10.0.45.2 source 10.200.1.1 PING 10.0.45.2 (10.0.45.2): 56 data bytes 64 bytes from 10.0.45.2: icmp_seq=0 ttl=63 time=3.953 ms 64 bytes from 10.0.45.2: icmp_seq=1 ttl=63 time=4.979 ms 64 bytes from 10.0.45.2: icmp_seq=2 ttl=63 time=3.789 ms
Meaning
The output shows a successful ping verifying the reachability to Device ISP from customer network 10.200.1.1.
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.