BGP Link-State¶
Overview¶
BGP Link-State, or BGP-LS, is an extension to BGP designed to carry Link-State information from an IGP. BGP-LS is primarily used in scenarios like TE, where a centralized controller (like a SDN controller) needs visibility into the network topology to make more intelligent routing decisions. Importantly, BGP-LS is solely an information carrier; it does not replace Link-State routing protocols like OSPF or IS-IS. Its purpose is not to contribute to the RIB or to influence routing decisions directly.
BGP-LS provides network controllers with an efficient means of gathering information from an IGP database, which was commonly achieved by connecting the controller to the IGP as a standard router. BGP-LS sidesteps the requirement for IGP Layer 2 adjacencies, which traditionally necessitated the use of Layer-2 tunnels like GRE to link IGP routers with centralized controllers. Unlike IGPs, BGP-LS is not involved in providing candidate paths to the RIB, serving purely as an information conduit. Moreover, BGP's inherent ability to relay information over multiple hops and across various domains offers flexibility, allowing network administrators to easily integrate BGP-LS into existing BGP setups.
Data Encoding¶
BGP-LS employs AFI 16388 and SAFI 71 to transport IGP information like OSPF or IS-IS to a centralized controller. The data conveyed includes key elements of the network topology, which are called descriptors:
Nodes: Representing routers in the network.
Link: Detailing the connections between these nodes.
IPv4 Prefix: IPv4 network addresses associated with these elements.
IPv6 Prefix: IPv6 network addresses associated with these elements.
These elements are encapsulated within the NLRI field in BGP-LS updates. To complement these descriptors, BGP-LS introduces a new set of BGP attributes, known as “BGP-LS attributes”, to carry additional context associated with the descriptors.
Both the NLRI descriptors and the BGP-LS attributes use the TLV encoding scheme which is already used by IS-IS in its LSPs and OSPF in its opaque LSAs. Nevertheless, BGP-LS TLV code-points and value formats are different from their equivalents in IS-IS and OSPF.
See also
The descriptors format is specified in in RFC 7752. For the attribute formats, the list of TLV , managed by the IANA provides the RFCs associated with the code points.
BGP-LS in Virtual Service Router¶
Virtual Service Router allows for participation in BGP-LS sessions using the designated AFI and SAFI to communicate with third-party routers. However, Virtual Service Router does not have the ability to build BGP-LS data based on OSPF or IS-IS information. In other words, it can act as a relay for BGP-LS information but not as a speaker. This makes it a suitable solution in designs where the objective is to relay BGP-LS information originating from equipment provided by third-party vendors. The Virtual Service Router BGP-LS can forward data to other BGP-LS-compatible peers or to the SDN controller directly.
Virtual Service Router forwards BGP-LS information encapsulated in NLRI and additional attributes without any modification. This is significant as the BGP-LS TLV codes are frequently updated through new RFCs. The Virtual Service Router's approach of leaving data untouched ensures its adaptability to any future changes or additions to the BGP-LS standard.
Configuration¶
The following example configures a BGP-LS peering with the 192.0.2.1
neighbor within AS 65002:
rt1 running config# / vrf main routing bgp as 65500
rt1 running config# / vrf main routing bgp router-id 10.1.1.1
rt1 running config# / vrf main routing bgp ebgp-requires-policy false
rt1 running config# / vrf main routing bgp address-family link-state-non-vpn enabled true
rt1 running config# / vrf main routing bgp neighbor 10.1.1.2 remote-as 65510
rt1 running config# / vrf main routing bgp neighbor 10.1.1.2 address-family link-state-non-vpn soft-reconfiguration-inbound true
rt1 running config# / vrf main routing bgp address-family ipv4-unicast redistribute connected
rt1 running config# / vrf main interface physical eth1 port pci-b0s4
rt1 running config# / vrf main interface physical eth1 ipv4 address 192.0.2.0/24
rt1 running config# / vrf main interface physical eth2 port pci-b0s5
rt1 running config# / vrf main interface physical eth2 ipv4 address 10.1.1.1/28
When connected to the appropriate peer, the received BGP-LS prefixes are displayed as follows:
rt1> show bgp link-state non-vpn
BGP table version is 4, local router ID is 10.1.1.1, vrf id 0
Default local pref 100, local AS 65500
Network Next Hop Metric LocPrf Weight Path
*> IPv6-Prefix OSPFv3 ID:0x20 {Local {AS:65001 ID:0 Area:0 Rtr:10.10.10.10} MT:2 OSPF-Route-Type:1 IPv6:12:12::12:12/128}/77
0 65510 i
*> IPv6-Prefix ISIS-L2 ID:0x20 {Local {AS:65001 ID:0 Rtr:0000.0000.1003.00} MT:2 IPv6:12:12::12:12/128}/67
0 65510 i
*> Node OSPFv2 ID:0x20 {Local {AS:65001 ID:0 Area:0 Rtr:10.10.10.10:1.1.1.1}}/49
0 65510 i
*> Node ISIS-L1 ID:0x20 {Local {AS:65001 ID:0 Rtr:0000.0000.1003.00}}/40
0 65510 i
Displayed 4 routes and 4 total paths
With the details:
rt1> show bgp link-state non-vpn detail-routes
BGP table version is 4, local router ID is 10.1.1.1, vrf id 0
Default local pref 100, local AS 65500
Network Next Hop Metric LocPrf Weight Path
65510
:: from 10.1.1.2 (10.1.1.2)
Origin IGP, valid, external, best (First path received)
Last update: Wed Jul 10 11:52:03 2024
65510
:: from 10.1.1.2 (10.1.1.2)
Origin IGP, valid, external, best (First path received)
Last update: Wed Jul 10 11:52:03 2024
65510
:: from 10.1.1.2 (10.1.1.2)
Origin IGP, valid, external, best (First path received)
Last update: Wed Jul 10 11:52:03 2024
65510
:: from 10.1.1.2 (10.1.1.2)
Origin IGP, valid, external, best (First path received)
Last update: Wed Jul 10 11:52:03 2024
BGP-LS attributes:
Multi-Topology ID: 0, 2
Node MSD:
Type: 8 Value: 1
Node Name: r3
IS-IS Area Identifier: 49.1000
IPv4 Router-ID of Local Node: 3.3.3.3
SR Capabilities:
Flags: 0b11000000
Range: 4000
SID/Label: From Label: 20000
SR Algorithm: 0, 128, 130
SR Local Block:
Flags: 0b00000000
Range: 1000
SID/Label: From Label: 15000
Displayed 4 routes and 4 total paths
Note
Virtual Service Router supports the display of the TLVs from the following RFCs:
RFC 5130 : A Policy Control Mechanism in IS-IS Using Administrative Tags
RFC 5305 : IS-IS Extensions for Traffic Engineering
RFC 5305 : IS-IS Extensions for Traffic Engineering
RFC 5307 : IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)
RFC 6119 : IPv6 Traffic Engineering in IS-IS
RFC 7752 : North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP
RFC 8169 : Residence Time Measurement in MPLS Networks
RFC 8379 : OSPF Graceful Link Shutdown
RFC 8571 : BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions
RFC 8814 : Signaling Maximum SID Depth (MSD) Using the Border Gateway Protocol - Link State
RFC 9085 : Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing
RFC 9086 : Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress Peer Engineering
RFC 9104 : Distribution of Traffic Engineering Extended Administrative Groups Using the Border Gateway Protocol - Link State (BGP-LS)
RFC 9247 : BGP - Link State (BGP-LS) Extensions for Seamless Bidirectional Forwarding Detection (S-BFD)
RFC 9294 : Application-Specific Link Attributes Advertisement Using the Border Gateway Protocol - Link State (BGP‑LS)
RFC 9351 : Border Gateway Protocol - Link State (BGP-LS) Extensions for Flexible Algorithm Advertisement
Unknown TLVs are displayed in the format: “TLV type <code-point>: <hexadecimal data>”.