Segment Routing v6 Configuration Guide for Cisco 8000 Series Routers, Cisco IOS XR Releases

PDF

Segment Routing v6 Configuration Guide for Cisco 8000 Series Routers, Cisco IOS XR Releases

Lightweight host routing using LLDP

Updated: September 8, 2026

Want to summarize with AI?

Explains how hosts and hypervisors advertise IPv6 prefixes or SRv6 locators through LLDP and describes the operational requirements, restrictions, and configuration process.

Lightweight host routing using LLDP is a host reachability mechanism that

uses LLDP to advertise host IPv6 prefixes or SRv6 locators to a directly connected Leaf or ToR router
removes the need to run a routing protocol stack on each host or hypervisor, and
enables the Leaf router to install LLDP-learned prefixes in the routing table and redistribute them into routing protocols such as IS-IS or BGP.

Table 1. Feature History Table
	Release information
Lightweight host routing using LLDP	Release 26.3.1	Introduced in this release on: Fixed Systems (8200 [ASIC: Q100,Q200, P100], 8700 [ASIC: P100, K100], 8010 [ASIC: A100]); Modular Systems (8800 [LC ASIC: K100)] You can now simplify host reachability by advertising IPv6 prefixes or SRv6 locators from a host or hypervisor to a directly connected Leaf or ToR router through LLDP IP Host Prefix TLVs. This process eliminates the need to run a routing protocol stack on each host or hypervisor. The Leaf router installs LLDP-learned prefixes in the routing table and redistributes them into routing protocols, including IS-IS and BGP.

Host prefix advertisement without host routing protocols

In a traditional host routing model, each host or hypervisor runs a routing stack and establishes a BGP session with the Leaf router to advertise host prefixes. This model adds routing configuration, session maintenance, and routing policy to every host. In large data center fabrics, this host-side routing dependency increases operational complexity and slows host onboarding.

Lightweight host routing using LLDP provides host reachability without requiring a routing protocol stack on each host or hypervisor. The host advertises its IPv6 prefix or SRv6 locator to the directly connected Leaf or ToR router by using an LLDP IP Host Prefix TLV. The Leaf router learns the prefix, installs it in the routing table, and redistributes it into IS-IS or BGP when redistribution is configured.

Key terms

Leaf or ToR router: A Leaf or ToR router is a directly connected router that receives LLDP prefix advertisements from a host or hypervisor and installs the learned prefix in the routing table.
Prefix redistribution: Prefix redistribution is the process of advertising an LLDP-learned prefix into a routing protocol such as IS-IS or BGP.
LLDP IP Host Prefix TLV: An LLDP IP Host Prefix TLV is an LLDP type-length-value field that carries IPv6 prefix or SRv6 locator information from a host or hypervisor to a directly connected Leaf router.
LLDP-learned prefix: An LLDP-learned prefix is an IPv6 prefix or SRv6 locator that the Leaf router learns from an LLDP IP Host Prefix TLV.

Benefits of lightweight host routing using LLDP

Lightweight host routing using LLDP simplifies host reachability in SRv6 fabric deployments by allowing a host or hypervisor to advertise IPv6 prefixes or SRv6 locators through LLDP instead of running a routing protocol stack. This feature provides these benefits:

Reduces host-side routing configuration: Hosts and hypervisors do not need to run a routing protocol stack, such as BGP, to advertise IPv6 prefixes or SRv6 locators. This reduces the routing configuration required on each host.
Simplifies host prefix advertisement: The host advertises its IPv6 prefix or SRv6 locator in an LLDP IP Host Prefix TLV. The directly connected Leaf router learns the prefix from the LLDP advertisement, which provides a lightweight method for advertising host reachability.
Uses LLDP for local prefix discovery: LLDP carries the host prefix information across the direct link between the host or hypervisor and the Leaf router. This allows the Leaf router to learn host reachability from the local LLDP neighbor.
Removes LLDP-learned prefixes when they are no longer advertised: The Leaf router withdraws learned prefixes when the LLDP neighbor expires, sends a shutdown frame, or stops advertising a prefix. This helps remove stale LLDP-learned prefix information from the routing table.
Enables SRv6 locator reachability for hosts and hypervisors: Hosts and hypervisors can advertise SRv6 locators to the directly connected Leaf router. The Leaf router can redistribute the learned locator into routing protocols such as IS-IS or BGP, making the locator reachable in the SRv6 fabric.

How lightweight host routing using LLDP works

Lightweight host routing using LLDP leverages LLDP advertisements to carry host prefix information from a host or hypervisor to a connected Leaf router. The router learns the prefix, installs it locally, and redistributes it into the broader routing domain based on routing policies.

Summary

The key components in lightweight host routing using LLDP are:

Host or hypervisor: Advertises an IPv6 prefix or SRv6 locator in an LLDP IP Host Prefix TLV.
Leaf router: Receives the LLDP advertisement, extracts the prefix information, and installs the learned prefix in the routing table.
Routing table: Maintains the LLDP-learned prefix and provides the prefix to routing protocols for redistribution.
Routing protocols: Redistribute the learned prefix into IS-IS, BGP, or both, based on the configured routing policy.
SRv6 fabric: Uses the redistributed prefix to route traffic to the host.

The host advertises the SRv6 locator fc00:0:11::/48 to ToR 1 and ToR 2 through LLDP. Each ToR learns the locator from the LLDP IP Host Prefix TLV and redistributes it into the SRv6 fabric through IS-IS or BGP.

Workflow

Figure 1. Tology diagram of lightweight host routing

These stages describe how lightweight host routing using LLDP works.

The host or hypervisor advertises an IPv6 prefix or SRv6 locator

The host or hypervisor includes the IPv6 prefix or SRv6 locator in an LLDP IP Host Prefix TLV. This advertisement allows the connected Leaf router to learn host reachability without
The Leaf router receives the LLDP advertisement.

The Leaf router receives the LLDP packet on a host-facing interface where lightweight host routing is enabled. This interface is the attachment point between the host and the SRv6 fabric.
The Leaf router extracts the prefix and its attributes.

The Leaf router reads the LLDP IP Host Prefix TLV and extracts the advertised prefix and related attributes. These attributes identify the prefix that must be installed and advertised into the network.
The Leaf router installs the learned prefix in the routing table.

After the prefix is validated, the Leaf router installs it as an LLDP-learned route in the routing table. The route provides local forwarding information for traffic destined to the host prefix or locator.
The routing table provides the learned prefix to the routing protocols.

The routing table makes the LLDP-learned prefix available to IS-IS, BGP, or both, depending on the configured redistribution policy. Redistribution controls which learned prefixes are advertised beyond the local Leaf router.
The routing protocol advertises the learned prefix into the SRv6 fabric.

IS-IS or BGP advertises the redistributed prefix to other routers in the SRv6 fabric. This advertisement makes the host prefix reachable from other parts of the network. The SRv6 fabric routes traffic to the host.
The SRv6 fabric routes traffic to the host.

Routers in the SRv6 fabric use the redistributed prefix to forward traffic toward the Leaf router that learned the host prefix. The Leaf router then forwards the traffic to the host through the host-facing interface.
The Leaf router withdraws the learned prefix when it is no longer valid.

The Leaf router removes the learned prefix if the LLDP neighbor ages out, sends a shutdown frame, or stops advertising the prefix. After the route is removed, the routing protocol withdraws the prefix from the SRv6 fabric.

Prefix withdrawal conditions

This table describes when the Leaf router withdraws an LLDP-learned prefix.

Table 2. Prefix withdrawal conditions
When	then
The LLDP neighbor expires	the Leaf router withdraws all prefixes learned from that neighbor
The host stops advertising a prefix in later LLDP messages	the Leaf router withdraws that prefix from the routing table.
The host sends an LLDP shutdown frame	the Leaf router withdraws the prefixes learned from that host.
The local host-facing interface goes down	the Leaf router withdraws the prefixes learned on that interface.

Restrictions for lightweight host routing using LLDP

Configure lightweight host routing using LLDP only on supported physical host-facing interfaces. Do not use lightweight host routing with LLDP on bundle interfaces, bundle subinterfaces, or untagged physical subinterfaces.

The Leaf router discards the LLDP IP Prefix TLV when the prefix information in the TLV exceeds the TLV length. The discarded TLV is not processed and the prefixes from that TLV are not installed in the routing table.

Guidelines to configure lightweight host routing using LLDP

Lightweight host routing using LLDP is disabled by default. Enable the feature globally and on each supported host-facing interface where the Leaf router must learn prefixes from LLDP advertisements.
The host or hypervisor must advertise IPv6 prefixes or SRv6 locators through the LLDP IP Host Prefix TLV. The Leaf router learns and installs only the prefixes that it receives through this TLV.
Enable this feature only on trusted host-facing interfaces. The Leaf router can install LLDP-learned prefixes in the routing table. Enabling the feature on untrusted interfaces can introduce unintended routes.

Enable lightweight host routing using LLDP

Lightweight host routing using LLDP is disabled by default. Enable the feature globally and on each supported host-facing interface where the Leaf router must learn prefixes from LLDP advertisements.

Procedure

Enable LLDP globally on the Leaf router.

Example:

Router# configure
Router(config)# lldp
Router(config)# interface HundredGigE0/0/0/1
Router(config-if)# lldp ipv6-prefix enable
Router(config-if)# commit

Configure redistribution based on the routing protocol and routing policy used in your network.

You can redistribute the LLDP-learned prefix into IS-IS, BGP, or both.

Example:


Router# configure
Router(config)# router isis core
Router(config-isis)# address-family ipv6 unicast
Router(config-isis-af)# redistribute application LLDP_IP_PREFIX 
Router(config-isis-af)# commit

Use this command to verify LLDP IP prefix packet statistics and confirm that the router is receiving IP prefix TLVs.

Example:

Router#show lldp ip-prefix 
IP Prefix Type	IP Prefix    Prefix Length	Flags	Algo	Metric	Nexthop IP		
Interface
------------------------------------------------------------------------------------------------------------------------------------------------------------------
SRv6 Locator    fc00:5:3::                              128 		0x81	0x80	0x0a	11::2                           HundredGigE0/0/0/1
SRv6 Locator    fc00:5:4::                              128 		0x81	0x80	0x0a	11::2                                   HundredGigE0/0/0/1
Total entries: 2

This example shows the output for each interface.

Router#show lldp ip-prefix hundredGigE 0/0/0/1
Wed Mar 11 04:21:50.882 UTC
IP Prefix Type	IP Prefix				Prefix Length	Flags	Algo	Metric	Nexthop IP			Interface
------------------------------------------------------------------------------------------------------------------------------------------------------------------
SRv6 Locator    fc00:5:3::                              128 		0x81	0x80	0x0a	11::2                                   HundredGigE0/0/0/1
SRv6 Locator    fc00:5:4::                              128 		0x81	0x80	0x0a	11::2                                   HundredGigE0/0/0/1
Total entries: 2
RP/0/RP0/CPU0:R1#

This example shows the output for the each location.

Router#show lldp ip-prefix location 0/RP0/CPU0 
Wed Mar 11 04:22:24.929 UTC
IP Prefix Type	IP Prefix				Prefix Length	Flags	Algo	Metric	Nexthop IP			Interface
------------------------------------------------------------------------------------------------------------------------------------------------------------------
SRv6 Locator    fc00:5:3::                              128 		0x81	0x80	0x0a	11::2                                   HundredGigE0/0/0/1
SRv6 Locator    fc00:5:4::                              128 		0x81	0x80	0x0a	11::2                                   HundredGigE0/0/0/1
Total entries: 2
RP/0/RP0/CPU0:R1#

Use this command to confirm that the host or hypervisor is detected as an LLDP neighbor on the host-facing interface.

Example:


Router#show lldp neighbors detail 
Capability codes:
	(R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
	(W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other
------------------------------------------------
Local Interface: HundredGigE0/0/0/1
Chassis id: 02a8.03b4.5aca
Port id: 02a8.03b4.5aca
Port Description: eth1
System Name: ubuntu22
System Description: 
Ubuntu 22.04.4 LTS Linux 5.15.0-78-generic #85-Ubuntu SMP Fri Jul 7 15:25:09 UTC 2023 x86_64
Time remaining: 112 seconds
Hold Time: 120 seconds
Age: 489358 seconds
System Capabilities: B,W,R,S
Enabled Capabilities: N/A
Management Addresses:
  IPv4 address: 1.0.0.2
  IPv6 address: 11::2
Peer MAC Address: 02:a8:03:b4:5a:ca
*** IP Prefixes ***
Prefix					Prefix Length
fc00:5:3::                              128             
fc00:5:4::                              128

Verify that the learned prefix is installed in the routing table.

Example:


Router#show route ipv6 fc00:0:11::/48

Routing entry for fc00:0:11::/48
Known via "application LLDP_IP_PREFIX", distance 10, metric 1
Installed Aug 28 08:59:13.324 for 01:04:03
Routing Descriptor Blocks
27::2, from c010:eb5d:7755::, via HundredGigE0/0/0/27
Route metric is 1
No advertising protos.

The learned prefix must be present in the routing table before it can be redistributed into the SRv6 fabric.

Need help?

Open a support case

(Requires a Cisco Service Contract)

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.