Hands-On Lab: Configuring BGP Route Summarization

This hands-on lab configures BGP route summarization using the aggregate-address command, advertising a single summarized route for several specific subnets while comparing the summary-only and summary-plus-specifics behavior options.

BGP Aggregate-AddressSummary-Only KeywordAS-Set Path Information

~3 دقیقه مطالعه · آخرین به‌روزرسانی ۴ مهر ۱۴۰۵

Lab Objective

Configure BGP route summarization on a router originating several specific subnets, first observing the default behavior of advertising both the summary and the specifics, then applying the summary-only keyword to suppress the specific routes entirely.

Lab Purpose

Route summarization, discussed earlier in this series for OSPF and EIGRP, applies equally to BGP but uses a distinct command. Reducing the number of prefixes advertised into the global internet routing table is a significant responsibility for any multi-homed organization, since unnecessary specific routes consume memory across every internet router that must carry a full routing table.

Lab Topology

R1 (AS 65100) originates four specific
subnets, all within a contiguous /22 block:

192.168.44.0/24
192.168.45.0/24
192.168.46.0/24
192.168.47.0/24

R1 ---- eBGP ---- R2 (AS 65200, external peer)

Task 1: Advertise the Four Specific Networks

Configure R1 to advertise all four specific /24 networks into BGP.

Task 2: Verify R2 Receives Four Specific Routes

Confirm R2's BGP table shows all four individual entries.

Task 3: Configure Basic Aggregation

Configure aggregate-address for the /22 summary covering all four subnets, without yet suppressing the specifics.

Task 4: Verify Both the Summary and Specifics Appear

Confirm R2 now sees both the new summary route and the original four specific routes.

Task 5: Apply Summary-Only to Suppress the Specifics

Reconfigure the aggregate with the summary-only keyword and verify only the summary route remains visible to R2.

Solution and Verification

R1(config)# router bgp 65100
R1(config-router)# network 192.168.44.0 mask 255.255.255.0
R1(config-router)# network 192.168.45.0 mask 255.255.255.0
R1(config-router)# network 192.168.46.0 mask 255.255.255.0
R1(config-router)# network 192.168.47.0 mask 255.255.255.0

R2# show ip bgp

   Network              Next Hop        Path
*> 192.168.44.0/24     [via R1]         65100 i
*> 192.168.45.0/24     [via R1]         65100 i
*> 192.168.46.0/24     [via R1]         65100 i
*> 192.168.47.0/24     [via R1]         65100 i
-- Four separate specific routes, before
-- any summarization is applied

R1(config)# router bgp 65100
R1(config-router)# aggregate-address 192.168.44.0 255.255.252.0

R2# show ip bgp

   Network              Next Hop        Path
*> 192.168.44.0/22     [via R1]         65100 i
*> 192.168.44.0/24     [via R1]         65100 i
*> 192.168.45.0/24     [via R1]         65100 i
*> 192.168.46.0/24     [via R1]         65100 i
*> 192.168.47.0/24     [via R1]         65100 i
-- The summary now exists ALONGSIDE the
-- specifics -- aggregate-address by default
-- adds a summary route without removing
-- the more specific ones already being
-- advertised

R1(config)# router bgp 65100
R1(config-router)# no aggregate-address 192.168.44.0 255.255.252.0
R1(config-router)# aggregate-address 192.168.44.0 255.255.252.0 summary-only

R2# show ip bgp

   Network              Next Hop        Path
*> 192.168.44.0/22     [via R1]         65100 i
-- Only the single summarized route remains
-- visible -- the summary-only keyword
-- suppressed all four specific /24
-- advertisements entirely

Key Takeaway

The aggregate-address command's default behavior of advertising the summary alongside the specifics is often not what an administrator actually wants — summary-only is required to achieve the genuine reduction in advertised prefixes that is usually the entire point of summarizing, and forgetting this keyword is a common mistake that leaves the routing table just as large as before while adding an extra, redundant summary route on top.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه