IS-IS Route Summarization
IS-IS splits a domain into areas across two levels. Splitting alone, however, does not reduce the number of IP routes. Prefixes inside a Level 1 area travel out through the routers that hold both levels (L1L2 routers) and are distributed across the whole domain. Ten areas with a hundred prefixes each put a thousand entries into Level 2.
Route summarization replaces a contiguous block of those prefixes with a single one at that exit. This article works through who summarizes and where, how the LSP changes, and what stops being visible — checking each against the RFC and against IOS XR.
Why summarize
RFC 1195 specifies the mechanism in section 3.2 under the name Hierarchical Abbreviation of IP Reachability Information.
Fewer prefixes lighten three things at once.
| What it helps | Why |
|---|---|
| Database size | Fewer entries in the LSPs, so the database every router holds gets smaller |
| Flooding | Prefixes coming and going inside the area no longer rebuild LSPs outside the summary |
| Route computation | SPF itself depends on the routers and links, but fewer prefixes are installed into the RIB afterwards |
The second one matters most: changes inside the area stop propagating outward. A component going up and down leaves the summarizing router’s LSP untouched, so the rest of the domain never hears about it.
The L1L2 router summarizes in its own LSP
OSPF’s area range tells an area border router to collapse its Type 3 LSAs, but IS-IS has no separate notion of an area range. An L1L2 router instead replaces the IP reachability entries it puts into its own Level 2 LSP, which is how RFC 1195 words it:
This is accomplished by manual configuration of summary addresses. Each level 2 router may be configured with one or more [IP address, subnet mask, metric] entries for announcement in their level 2 LSPs.
Whether a configured address replaces something is decided by range alone:
The configured addresses will supercede reachable address entries from level 1 LSPs based only on the IP address and subnet mask – metric values are not considered when determining if a given configured address supercedes an address obtained from a level 1 LSP.
Component prefixes that fall inside the summary disappear from that router’s Level 2 LSP. From outside the area, only the summary is visible.
The metric is not implied
The metric of a summarized prefix is not derived mechanically from its components. RFC 1195 has it configured alongside the address:
For manually configured level 2 addresses, the associated metric values to announce in level 2 LSPs are also manually configured.
Entries that are not summarized work differently — those are computed:
the metric value announced in the level 2 LSPs is calculated from the sum of the metric value announced in the corresponding level 1 LSP, plus the distance from the level 2 router to the appropriate level 1 router.
IOS XR 26.1.1 (XRd) has no syntax for setting the metric of a summary. What may follow summary-prefix is adv-unreachable, algorithm, explicit, level, partition-repair or tag; metric returns % Invalid input detected. The value the RFC has you configure is one this implementation decides for itself.
Cisco states the rule it uses. From the IS-IS configuration guide:
The metric used to advertise the summary is the smallest metric of all the more-specific routes.
Taking the smallest keeps the summary from looking further away than it is. When a summary covers both near and far destinations, pricing it at the far one would degrade the path selection towards the near ones as well. The lab below weights a single component to confirm the rule.
What summarization hides
The benefit and the hazard are the same property. As long as one component prefix survives, the summary keeps being advertised.
If 172.16.1.0/24 disappears inside the area, 172.16.0.0/22 is still advertised. Routers outside keep sending packets towards that /22; they reach the summarizing router and run out of road there.
A router that summarizes still knows the component prefixes itself. Only what it advertises changes; the specific routes stay in its own table, so packets for destinations that do exist are forwarded normally.
A discard route catches those. The router configured to summarize installs a route for the summary prefix pointing at Null0 in its own RIB. Packets for a destination that has gone away travel as far as the summarizing router and are dropped there — no loop, and the sender gets an ICMP unreachable.
When an area has several exits, configure the same summary on all of them. A single router left unsummarized keeps advertising the component prefixes, and receivers use the longest match, so traffic gravitates to that exit even when the summarized one has the lower metric.
Summarization and addressing plans are one subject. Unless each area owns a contiguous block, there is nothing to collapse. When prefixes from the same block are scattered across several areas, every one of those areas advertises the same summary and traffic is drawn into areas that have nothing to do with the destination.
Note that ISO/IEC 10589:2002 (second edition), the IS-IS specification itself, has no mechanism for carrying IP prefixes at all, so it does not specify summarization either. This is part of the extension that carries IP routes over IS-IS (RFC 1195).
Verification on real devices
The test setup
Area 49.0001 holds R1, R2 and R3, with only R1 configured as level-1. R2 and R3 are level-1-2 and connect to R4, a level-2-only router in area 49.0002. R1 carries Loopback1 to Loopback4 (172.16.0.1/24 to 172.16.3.1/24), and those are what gets summarized — together they make 172.16.0.0/22.
| Router | Area | IS type | Loopbacks | Links |
|---|---|---|---|---|
| R1 | 49.0001 | level-1 | Lo0 1.1.1.1/32, Lo1-Lo4 172.16.0-3.1/24 | Gi0/0/0/0 10.1.2.1 (to R2, metric 10), Gi0/0/0/1 10.1.3.1 (to R3, metric 20) |
| R2 | 49.0001 | level-1-2 | Lo0 2.2.2.2/32 | Gi0/0/0/0 10.1.2.2, Gi0/0/0/1 10.2.4.2 (to R4) |
| R3 | 49.0001 | level-1-2 | Lo0 3.3.3.3/32 | Gi0/0/0/0 10.1.3.3, Gi0/0/0/1 10.3.4.3 (to R4) |
| R4 | 49.0002 | level-2-only | Lo0 4.4.4.4/32 | Gi0/0/0/0 10.2.4.4, Gi0/0/0/1 10.3.4.4 |
Only R2 is configured to summarize; R3 is left alone. From R4, the same routes in the same area are visible both summarized and unsummarized at the same time, which makes the difference directly readable.
The STEPs
| STEP | Operation | What it confirms |
|---|---|---|
| 0 | Defaults, no summarization | The four component prefixes appear in both R2’s and R3’s Level 2 LSPs |
| 1 | Configure the 172.16.0.0/22 summary on R2 | R2’s LSP loses the four components and carries one summary; what metric it gets |
| 2 | Set the metric of Lo1 on R1 to 50 | What metric the summary takes |
| 3 | Remove Lo1 from IS-IS on R1 | R2’s summary stays; only R3’s side drops to three prefixes |
| 4 | Remove Lo2 to Lo4 as well | R2’s summary disappears |
| 5 | Revert everything (final state) | Matches STEP 0 |
STEP 0: without summarization the components travel as they are
R4’s routing table, seen from the other area:
RP/0/RP0/CPU0:R4#show route isis
Sat Sep 12 01:48:54.621 UTC
i L2 1.1.1.1/32 [115/20] via 10.2.4.2, 00:12:07, GigabitEthernet0/0/0/0
i L2 2.2.2.2/32 [115/10] via 10.2.4.2, 00:12:07, GigabitEthernet0/0/0/0
i L2 3.3.3.3/32 [115/10] via 10.3.4.3, 00:12:07, GigabitEthernet0/0/0/1
i L2 10.1.2.0/24 [115/20] via 10.2.4.2, 00:12:07, GigabitEthernet0/0/0/0
i L2 10.1.3.0/24 [115/30] via 10.3.4.3, 00:12:07, GigabitEthernet0/0/0/1
i L2 172.16.0.0/24 [115/20] via 10.2.4.2, 00:12:07, GigabitEthernet0/0/0/0
i L2 172.16.1.0/24 [115/20] via 10.2.4.2, 00:12:07, GigabitEthernet0/0/0/0
i L2 172.16.2.0/24 [115/20] via 10.2.4.2, 00:12:07, GigabitEthernet0/0/0/0
i L2 172.16.3.0/24 [115/20] via 10.2.4.2, 00:12:07, GigabitEthernet0/0/0/0All four prefixes from 172.16.0.0/24 to 172.16.3.0/24 have crossed into the other area untouched. The metric of 20 is R2’s 10 to R1 plus R4’s 10 to R2 — exactly what RFC 1195 describes as “the metric value announced in the corresponding level 1 LSP, plus the distance from the level 2 router to the appropriate level 1 router”.
STEP 1: configure the summary on R2
One line on R2. level 2 confines it to the Level 2 side.
router isis 1
address-family ipv4 unicast
summary-prefix 172.16.0.0/22 level 2R4’s database:
RP/0/RP0/CPU0:R4#show isis database detail
Sat Sep 12 02:06:41.494 UTC
IS-IS 1 (Level-2) Link State Database
LSPID LSP Seq Num LSP Checksum LSP Holdtime/Rcvd ATT/P/OL
R2.00-00 0x0000000b 0x2aa0 1058 /1200 0/0/0
Area Address: 49.0001
LSP MTU: 1492
NLPID: 0xcc
IP Address: 2.2.2.2
Hostname: R2
Metric: 10 IS-Extended R4.00
Metric: 10 IP-Extended 1.1.1.1/32
Metric: 0 IP-Extended 2.2.2.2/32
Metric: 30 IP-Extended 3.3.3.3/32
Metric: 10 IP-Extended 10.1.2.0/24
Metric: 30 IP-Extended 10.1.3.0/24
Metric: 10 IP-Extended 10.2.4.0/24
Metric: 40 IP-Extended 10.3.4.0/24
Metric: 10 IP-Extended 172.16.0.0/22
R3.00-00 0x00000009 0x6561 983 /1200 0/0/0
Area Address: 49.0001
LSP MTU: 1492
NLPID: 0xcc
IP Address: 3.3.3.3
Hostname: R3
Metric: 10 IS-Extended R4.00
Metric: 20 IP-Extended 1.1.1.1/32
Metric: 30 IP-Extended 2.2.2.2/32
Metric: 0 IP-Extended 3.3.3.3/32
Metric: 30 IP-Extended 10.1.2.0/24
Metric: 20 IP-Extended 10.1.3.0/24
Metric: 40 IP-Extended 10.2.4.0/24
Metric: 10 IP-Extended 10.3.4.0/24
Metric: 20 IP-Extended 172.16.0.0/24
Metric: 20 IP-Extended 172.16.1.0/24
Metric: 20 IP-Extended 172.16.2.0/24
Metric: 20 IP-Extended 172.16.3.0/24
R4.00-00 * 0x00000008 0xb25c 861 /* 0/0/0
Area Address: 49.0002
LSP MTU: 1492
NLPID: 0xcc
IP Address: 4.4.4.4
Hostname: R4
Metric: 10 IS-Extended R2.00
Metric: 10 IS-Extended R3.00
Metric: 0 IP-Extended 4.4.4.4/32
Metric: 10 IP-Extended 10.2.4.0/24
Metric: 10 IP-Extended 10.3.4.0/24
Total Level-2 LSP count: 3 Local Level-2 LSP count: 1The four components have gone from R2’s LSP, leaving one line: 172.16.0.0/22, at metric 10. R3, which was left alone, still carries all four, so the same routes from the same area are now advertised both ways at once.
R2’s own routing table changes too.
RP/0/RP0/CPU0:R2#show route 172.16.0.0/22
Sat Sep 12 02:06:11.017 UTC
Routing entry for 172.16.0.0/22
Known via "isis 1", distance 115, metric 10 (summary), type manual summary
Installed Sep 12 02:04:19.948 for 00:01:51
Routing Descriptor Blocks
directly connected, via Null0
Route metric is 10
No advertising protos. It reads type manual summary with Null0 as the next hop. Packets for the /22 that R2 itself advertised are dropped here unless a more specific route matches.
What R2 itself knows does not change.
RP/0/RP0/CPU0:R2#show route isis
Sat Sep 12 02:06:10.843 UTC
i L1 1.1.1.1/32 [115/10] via 10.1.2.1, 00:35:12, GigabitEthernet0/0/0/0
i L1 3.3.3.3/32 [115/30] via 10.1.2.1, 00:32:09, GigabitEthernet0/0/0/0
i L2 4.4.4.4/32 [115/10] via 10.2.4.4, 00:29:24, GigabitEthernet0/0/0/1
i L1 10.1.3.0/24 [115/30] via 10.1.2.1, 00:35:12, GigabitEthernet0/0/0/0
i L1 10.3.4.0/24 [115/40] via 10.1.2.1, 00:32:09, GigabitEthernet0/0/0/0
i su 172.16.0.0/22 [115/10] via 0.0.0.0, 00:01:50, Null0
i L1 172.16.0.0/24 [115/10] via 10.1.2.1, 00:35:12, GigabitEthernet0/0/0/0
i L1 172.16.1.0/24 [115/10] via 10.1.2.1, 00:35:12, GigabitEthernet0/0/0/0
i L1 172.16.2.0/24 [115/10] via 10.1.2.1, 00:35:12, GigabitEthernet0/0/0/0
i L1 172.16.3.0/24 [115/10] via 10.1.2.1, 00:35:12, GigabitEthernet0/0/0/0The i su line is the summary pointing at Null0, and the four components (i L1) are still there underneath it. Summarization changes what a router advertises, not what it knows. R2 forwards a packet for 172.16.1.5 to R1 on the longer-matching /24; only addresses that match no component get dropped.
In R4’s table the summary and the components sit side by side.
RP/0/RP0/CPU0:R4#show route isis
Sat Sep 12 02:06:40.367 UTC
i L2 1.1.1.1/32 [115/20] via 10.2.4.2, 00:29:53, GigabitEthernet0/0/0/0
i L2 2.2.2.2/32 [115/10] via 10.2.4.2, 00:29:53, GigabitEthernet0/0/0/0
i L2 3.3.3.3/32 [115/10] via 10.3.4.3, 00:29:53, GigabitEthernet0/0/0/1
i L2 10.1.2.0/24 [115/20] via 10.2.4.2, 00:29:53, GigabitEthernet0/0/0/0
i L2 10.1.3.0/24 [115/30] via 10.3.4.3, 00:29:53, GigabitEthernet0/0/0/1
i L2 172.16.0.0/22 [115/20] via 10.2.4.2, 00:02:20, GigabitEthernet0/0/0/0
i L2 172.16.0.0/24 [115/30] via 10.3.4.3, 00:02:20, GigabitEthernet0/0/0/1
i L2 172.16.1.0/24 [115/30] via 10.3.4.3, 00:02:20, GigabitEthernet0/0/0/1
i L2 172.16.2.0/24 [115/30] via 10.3.4.3, 00:02:20, GigabitEthernet0/0/0/1
i L2 172.16.3.0/24 [115/30] via 10.3.4.3, 00:02:20, GigabitEthernet0/0/0/1The /22 is metric 20 through R2; the three /24s are 30 through R3. What R4 uses for 172.16.1.5 is not the cheaper /22 but the longer match, the /24. Where some routers summarize and others do not, traffic gravitates to the ones that do not.
STEP 2: changing a component’s metric leaves the summary alone
Loopback1 on R1 (172.16.0.0/24) is given a metric of 50, making that route 80 through R3 (20 + 50 + 10).
RP/0/RP0/CPU0:R4#show route isis
Sat Sep 12 02:09:25.603 UTC
i L2 1.1.1.1/32 [115/20] via 10.2.4.2, 00:32:38, GigabitEthernet0/0/0/0
i L2 2.2.2.2/32 [115/10] via 10.2.4.2, 00:32:38, GigabitEthernet0/0/0/0
i L2 3.3.3.3/32 [115/10] via 10.3.4.3, 00:32:38, GigabitEthernet0/0/0/1
i L2 10.1.2.0/24 [115/20] via 10.2.4.2, 00:32:38, GigabitEthernet0/0/0/0
i L2 10.1.3.0/24 [115/30] via 10.3.4.3, 00:32:38, GigabitEthernet0/0/0/1
i L2 172.16.0.0/22 [115/20] via 10.2.4.2, 00:05:05, GigabitEthernet0/0/0/0
i L2 172.16.0.0/24 [115/80] via 10.3.4.3, 00:02:29, GigabitEthernet0/0/0/1
i L2 172.16.1.0/24 [115/30] via 10.3.4.3, 00:05:05, GigabitEthernet0/0/0/1
i L2 172.16.2.0/24 [115/30] via 10.3.4.3, 00:05:05, GigabitEthernet0/0/0/1
i L2 172.16.3.0/24 [115/30] via 10.3.4.3, 00:05:05, GigabitEthernet0/0/0/1172.16.0.0/24 through R3 has risen to 80, while the /22 stays at 20. The components behind the summary are now 60 (as R2 sees them), 10, 10 and 10, and what the summary took is the smallest, 10 — not the first component, and not the largest.
STEP 3: losing a component does not even rebuild the summarizing router’s LSP
Loopback1 is removed from IS-IS on R1, so one route disappears inside the area.
RP/0/RP0/CPU0:R4#show isis database
Sat Sep 12 02:06:41.375 UTC
IS-IS 1 (Level-2) Link State Database
LSPID LSP Seq Num LSP Checksum LSP Holdtime/Rcvd ATT/P/OL
R2.00-00 0x0000000b 0x2aa0 1058 /1200 0/0/0
R3.00-00 0x00000009 0x6561 983 /1200 0/0/0
R4.00-00 * 0x00000008 0xb25c 861 /* 0/0/0
Total Level-2 LSP count: 3 Local Level-2 LSP count: 1RP/0/RP0/CPU0:R4#show isis database
Sat Sep 12 02:12:02.877 UTC
IS-IS 1 (Level-2) Link State Database
LSPID LSP Seq Num LSP Checksum LSP Holdtime/Rcvd ATT/P/OL
R2.00-00 0x0000000b 0x2aa0 736 /1200 0/0/0
R3.00-00 0x0000000b 0xa1a0 1060 /1200 0/0/0
R4.00-00 * 0x00000008 0xb25c 539 /* 0/0/0
Total Level-2 LSP count: 3 Local Level-2 LSP count: 1Compare the two. R2’s LSP still carries the same sequence number and checksum, 0x0000000b / 0x2aa0. Two changes happened inside the area — the metric in STEP 2 and the removal here — and R2 never rebuilt its LSP. R3, which does not summarize, went from 0x00000009 to 0x0000000b, two regenerations.
Seen from outside the area, changes behind the summary did not even trigger an LSP regeneration. That is precisely the mechanism by which summarization reduces flooding.
STEP 4: when every component is gone, so is the summary
Loopback2 to Loopback4 are removed as well, leaving nothing inside the summary range.
RP/0/RP0/CPU0:R4#show route isis
Sat Sep 12 02:14:39.283 UTC
i L2 1.1.1.1/32 [115/20] via 10.2.4.2, 00:37:52, GigabitEthernet0/0/0/0
i L2 2.2.2.2/32 [115/10] via 10.2.4.2, 00:37:52, GigabitEthernet0/0/0/0
i L2 3.3.3.3/32 [115/10] via 10.3.4.3, 00:37:52, GigabitEthernet0/0/0/1
i L2 10.1.2.0/24 [115/20] via 10.2.4.2, 00:37:52, GigabitEthernet0/0/0/0
i L2 10.1.3.0/24 [115/30] via 10.3.4.3, 00:37:52, GigabitEthernet0/0/0/1Every 172.16 line is gone, and R2’s discard route goes with them.
RP/0/RP0/CPU0:R2#show route 172.16.0.0/22
Sat Sep 12 02:14:09.154 UTC
% Network not in tableThe summary-prefix configuration is still in place, but with no route inside the range there is nothing to advertise. The discard route exists only while the summary is being advertised.
STEP 5: revert
Loopback1 to Loopback4 go back into IS-IS and the summary is removed from R2. The running-config of all four routers matches STEP 0, and R2’s and R3’s LSPs carry the same contents as they did at STEP 0.
Verification configs and show output
Each STEP was captured from all four routers as three files per router. The verification config is the ..._run.txt (the final state is the one from the last STEP).
| File | Contents |
|---|---|
..._show.txt | show version, show interface description, show route, the show isis set (interface brief, neighbors, database detail, topology, route, adjacency-log, spf-log, lsp-log, statistics), and show route 172.16.0.0/22 |
..._log.txt | show logging narrowed to that STEP. A logmsg marker is placed at the start of each STEP and its timestamp passed to show logging start |
..._run.txt | show running-config at that STEP (the verification config for that STEP) |
STEP 0: Initial state (no summarization)
| Router | show | syslog | running-config |
|---|---|---|---|
| R1 | show | log | run |
| R2 | show | log | run |
| R3 | show | log | run |
| R4 | show | log | run |
STEP 1: Configure the 172.16.0.0/22 summary on R2
| Router | show | syslog | running-config |
|---|---|---|---|
| R1 | show | log | run |
| R2 | show | log | run |
| R3 | show | log | run |
| R4 | show | log | run |
STEP 2: Set the metric of Lo1 on R1 to 50
| Router | show | syslog | running-config |
|---|---|---|---|
| R1 | show | log | run |
| R2 | show | log | run |
| R3 | show | log | run |
| R4 | show | log | run |
STEP 3: Remove Lo1 from IS-IS on R1
| Router | show | syslog | running-config |
|---|---|---|---|
| R1 | show | log | run |
| R2 | show | log | run |
| R3 | show | log | run |
| R4 | show | log | run |
STEP 4: Remove Lo2 to Lo4 as well
| Router | show | syslog | running-config |
|---|---|---|---|
| R1 | show | log | run |
| R2 | show | log | run |
| R3 | show | log | run |
| R4 | show | log | run |
STEP 5: Revert everything (final state)
| Router | show | syslog | running-config |
|---|---|---|---|
| R1 | show | log | run |
| R2 | show | log | run |
| R3 | show | log | run |
| R4 | show | log | run |
References
| Standard | Title | Summary |
|---|---|---|
| RFC 1195 | Use of OSI IS-IS for Routing in TCP/IP and Dual Environments | The extension that carries IP routes over IS-IS. Section 3.2, “Hierarchical Abbreviation of IP Reachability Information”, specifies summarization: the summary address and its metric are configured manually, the metric plays no part in deciding what a configured address supersedes, and the metric of an unsummarized entry is computed from the Level 1 metric plus the distance to that Level 1 router. |
| RFC 5305 | IS-IS Extensions for Traffic Engineering | Wide metrics. Defines TLV 135 (Extended IP Reachability), which this test uses. |
| Cisco IS-IS configuration guide (IOS XE 17.x) | Customizing IS-IS for Your Network Design | States that the metric advertised for a summary is “the smallest metric of all the more-specific routes” — the documented rule behind the value RFC 1195 leaves to manual configuration. |
| Cisco ASR 9000 Routing Command Reference | IS-IS Commands | The IOS XR summary-prefix command. Besides level, used here, it takes adv-unreachable, algorithm, explicit, partition-repair and tag. There is no argument for a metric (confirmed on XRd 26.1.1, the device used for this article). |
| ISO/IEC 10589:2002 (second edition) | Intermediate System to Intermediate System intra-domain routeing information exchange protocol | The IS-IS specification itself. It carries no IP prefixes, and so specifies no route summarization either. |
Related articles
- What Is IS-IS
- IS-IS NSAP Addresses and the NET (System ID)
- IS-IS Level 1 and Level 2 (the hierarchy)
- IS-IS Packet Types and Header Format
- IS-IS Adjacency Formation and States
- IS-IS DIS and the Pseudonode
- IS-IS Network Types (broadcast / point-to-point)
- IS-IS Metrics (narrow and wide)
- IS-IS Authentication (hello-password and lsp-password)
- IS-IS LSPs and the Link-State Database
- The Main IS-IS TLVs
- IS-IS Flooding and LSDB Synchronisation
- IS-IS SPF Computation and Route Selection
- The IS-IS ATT Bit and the Level 1 Default Route
- IS-IS Route Leaking and the Up/Down Bit
- IS-IS Route Summarization