Intermediate System to Intermediate System (IS-IS) is a link-state routing protocol that uses Type-Length-Value (TLV) encoding to carry routing information. Understanding TLVs and sub-TLVs is crucial for network engineers working with modern service provider networks, especially those implementing Segment Routing, Traffic Engineering, and IPv6.
What are TLVs in IS-IS?
TLVs provide an extensible framework for IS-IS to carry various types of routing information within Link State PDUs (LSPs). Each TLV consists of three components:
- Type: 1-byte field identifying the TLV purpose
- Length: 1-byte field indicating the value length
- Value: Variable-length field containing the actual data
This flexible structure allows IS-IS to evolve by adding new TLVs without breaking existing implementations—a key advantage over fixed-format protocols.
Essential IS-IS TLVs
TLV 1: Area Addresses
Identifies the IS-IS area(s) to which a router belongs. Critical for multi-area deployments.
Example: 49.0001 (Area 1)
Format: [AFI][Area ID][System ID][SEL]TLV 2: IS Reachability (Narrow)
Advertises neighbor routers with narrow (6-bit) metric. Legacy format, largely replaced by Extended IS Reachability.
TLV 22: Extended IS Reachability
Modern replacement for TLV 2, supporting 24-bit wide metrics and sub-TLVs for advanced features.
Practical Implementation
Decoding TLV 22 in LSP
show isis database verbose
Extended IS Reachability TLV #22, length: 23
Neighbor: R2.00, Metric: 10
Sub-TLVs:
IPv4 Interface Address (6): 10.1.1.1
Admin Group (3): 0x00000001
Maximum Link Bandwidth (9): 1000000 Kbps
TE Default Metric (18): 10This output shows TLV 22 advertising a link to R2 with metric 10, plus four sub-TLVs providing Traffic Engineering information.
TLV 128/130: IP Internal/External Reachability
Narrow metric format for IPv4 prefixes. TLV 128 for internal routes, TLV 130 for external (redistributed) routes.
TLV 135: Extended IP Reachability
Wide metric successor to TLV 128/130. Supports VLSM and sub-TLVs for prefix attributes.
# Example: Advertising 192.168.1.0/24 with metric 20
TLV 135, length: 12
Metric: 20, Prefix: 192.168.1.0/24
Sub-TLV: Prefix-SID (3), Index: 1TLV 232: IPv6 Interface Address
Advertises IPv6 addresses assigned to router interfaces, enabling IPv6 routing topology formation.
TLV 236: IPv6 Reachability
The IPv6 equivalent of TLV 135, advertising IPv6 prefixes with wide metrics and sub-TLV support.
Critical Sub-TLVs for Modern Networks
Sub-TLV 3: Prefix-SID (Segment Routing)
Carries the Segment Routing identifier for IPv4/IPv6 prefixes, enabling SR-MPLS and SRv6 deployments.
Practical Implementation
Configuring Prefix-SID
router isis CORE
interface Loopback0
address-family ipv4 unicast
prefix-sid index 100
!
!
!This assigns prefix-SID index 100, which translates to label SRGB_START + 100 (e.g., 16000 + 100 = 16100).
Sub-TLV 4: Adjacency-SID
Advertises Segment Routing labels for specific adjacencies, enabling strict hop-by-hop path control.
Sub-TLV 6: IPv4 Interface Address
Nested within TLV 22, this sub-TLV provides the IPv4 address of the advertising interface for TE applications.
Sub-TLV 8: IPv4 Neighbor Address
Specifies the neighbor’s IPv4 address on the link, crucial for point-to-point link identification.
Sub-TLV 9: Maximum Link Bandwidth
Traffic Engineering parameter indicating the physical bandwidth of the link in bytes/second.
Sub-TLV 11: Unreserved Bandwidth
Advertises available bandwidth at 8 different priority levels (0-7) for RSVP-TE or SR-TE path computation.
Sub-TLV 18: TE Default Metric
Allows separate metrics for IGP routing versus Traffic Engineering path calculations.
Sub-TLV 22: Shared Risk Link Group (SRLG)
Identifies sets of links sharing common failure risks (same conduit, fiber bundle, etc.) for diverse path computation.
TLV Extensions for Advanced Features
TLV 242: IS-IS Router Capability
Announces router-level capabilities such as:
- Segment Routing support (SRGB range)
- Segment Routing algorithms (SPF, Strict-SPF)
- SR Local Block (SRLB) for local segments
show isis database verbose R1.00-00
Router Capability TLV #242
Router ID: 192.168.1.1
Sub-TLVs:
SR Capability (2):
Flags: IPv4, MPLS
SRGB: [16000-23999]
SR Algorithm (19): SPFLaboratory Exercise
Analyzing TLVs with Wireshark
Capture IS-IS packets and examine TLV structure:
- Start capture on IS-IS interface:
monitor capture CAP interface Gi0/0/0/0 - Filter for IS-IS:
isis - Expand LSP → TLVs → Individual TLV/sub-TLV fields
- Verify encoding matches RFC specifications
Key fields to examine:
- PDU Type (LSP = 0x12)
- TLV Type codes
- Length fields matching actual data
- Metric values (10-bit narrow vs 24-bit wide)
TLV Troubleshooting
Common Issues
| Problem | Likely Cause | Solution |
|---|---|---|
| Missing routes | TLV 135/236 not advertised | Check metric-style wide |
| TE tunnels fail | Missing sub-TLV 9/11 | Enable MPLS TE on interface |
| SR labels absent | No Prefix-SID sub-TLV | Configure segment-routing mpls |
| Adjacency down | TLV 1 mismatch | Align area addresses |
Verification Commands
# Display all TLVs in LSP database
show isis database verbose
# Show specific TLV types
show isis database detail | include "TLV|Sub-TLV"
# Verify segment routing TLVs
show isis segment-routing prefix-sids
# Check TE-related sub-TLVs
show mpls traffic-eng topologyBest Practices
- Always use wide metrics (metric-style wide) for scalability
- Enable necessary TLV extensions explicitly (SR, TE, IPv6)
- Monitor LSP database size—excessive TLVs can cause flooding storms
- Implement TLV filtering on area boundaries to reduce overhead
- Document custom TLV usage if implementing proprietary extensions
Conclusion
IS-IS TLVs and sub-TLVs form the backbone of modern routing protocol extensibility. From basic reachability (TLV 22, 135) to advanced Segment Routing (sub-TLV 3, 4) and Traffic Engineering (sub-TLVs 9, 11, 18), mastering these structures is essential for deploying scalable service provider networks.
The modular TLV architecture ensures IS-IS remains relevant as new technologies emerge, making it the IGP of choice for large-scale MPLS and Segment Routing deployments.
Parveen Jindgar
Engineering Leader
I am an engineering leader with over 20 years of experience working on large-scale packet networks in Service Provider and latency-sensitive environments. My work has centered on end-to-end architectural ownership of backbone and edge infrastructures — spanning platform and vendor selection, routing and control-plane design, and the evolution of networks under real operational and economic constraints. PacketBytes is a personal space where I document the engineering thinking behind these systems — examining architectures, control planes, and design trade-offs as they behave under real traffic, real failures, and real operational pressure, beyond configuration and into intent.