BGP Link State (BGP-LS) Producer for IS-IS LSDB

eos.arista.com/eos-4-24-2f/bgp-link-state-bgp-ls-producer-for-is-is-lsdb

By Nandan Saha

Contents [hide]

Description
BGP-LS AFI/SAFI
BGP-LS NLRI
Fields common to all NLRI types
Node NLRI
Node Descriptor
Link NLRI
2-way connectivity check
Link Descriptor
Prefix NLRI
Prefix Descriptor
BGP-LS path attribute
Node Attribute
Link Attribute
Prefix Attribute
BGP-LS advertisement of IS-IS link NLRI when traffic-engineering is not enabled
BGP-LS Tx Update generation rate as propagator
Behavior on reception of BGP-LS Updates
BGP Additional Paths (Add-Path)
BGP-LS advertisement of unreachable nodes
Inbound route-map
Outbound route-map
“bgp missing-policy action” interaction
BGP-LS behavior on Isis agent restart
Platform Compatibility
Configuration
Configuring BGP-LS on a BGP peer
Configuring import of IS-IS LSDB into BGP

1/25
 Show Commands
show bgp link-state summary
show bgp link-state [node | link | ipv4-prefix | ipv6-prefix]
show bgp link-state [node | link | ipv4-prefix | ipv6-prefix ] detail
show bgp link-state node detail
show bgp neighbor <PEER_ADDRESS> link-state advertised-routes
show bgp link-state link detail
show bgp link-state ipv4-prefix detail
show bgp link-state ipv6-prefix detail
show tech-support bgp link-state
show tech-support extended bgp link-state
Changes to existing show commands
show <ip | ipv6> bgp neighbors [PEER_ADDR]
show ip bgp peer-group <PEER_GROUP_NAME>
show bgp instance
Syslog Messages
Troubleshooting
Collecting Information for Problem Reporting
Tracing
Limitations
Resources

Description
The BGP-LS extension (RFC7752/to be obsoleted by draft-ietf-idr-rfc7752bis) allows IGP
(OSPF/IS-IS) link state database information to be injected into BGP. This is typically used in
deployments where some external component, (like a controller or Path Computation
Engine) can do centralized path computations by learning the entire IGP topology through
BGP-LS. The controller can then communicate the computed paths based on the BGP-LS
updates to the head end device in the network. The mechanism used by the controller to
communicate the computed TE paths is outside the scope of this document. Using BGP-LS
instead of an IGP peering with the controller to distribute IGP link state information has the
following advantages.

Eliminates the need for the controller to implement the IGP listener.
Avoids the controller from being overwhelmed with too many IGP updates and
potentially helps with the performance of the controller.
In a network with multiple IGP domains, we can use BGP-LS to aggregate the link state
information across all the domains and send it to the controller.
Using BGP also allows the user to apply policies to the link state information

2/25
In the above diagram, we see that IGP nodes A2 and B2 advertise the link state information
from their IGP domain through BGP-LS to a BGP-LS speaker which in turn will advertise the
BGP-LS updates to the controller. The controller will in turn program the TE paths on the
head end router A1 based on its computations.
EOS-4.24.2 adds support for BGP-LS in the “producer” role supporting importing the IS-IS
LSDB in default VRF for non multi-topology IS-IS on P2P links into BGP and advertising the
BGP-LS paths to BGP-LS peers. The supported features in EOS-4.24.2 in BGP-LS are
targeted at networks making use of traffic engineering or segment routing traffic engineering
to control traffic flows in the networks. BGP-LS support is available only in the multi-agent
routing model.

Starting EOS-4.26.1, there is also support for importing multiple IS-IS instances into BGP-LS
on platforms that support multiple IS-IS instances.

BGP-LS AFI/SAFI
Of the 2 AFI/SAFI types defined in draft-ietf-idr-rfc7752bis, EOS-4.24.2 supports the non-
VPN AFI 16388 / SAFI 71.
AFI 16388 / SAFI 72 is NOT supported.

BGP-LS NLRI
EOS-4.24.2 supports the following NLRI types defined in Table-1 of
https://tools.ietf.org/html/draft-ietf-idr-rfc7752bis-06#section-4.2

1. Node NLRI (NLRI Type=1)

2. Link NLRI (NLRI Type=2)
3. IPv4 prefix NLRI (NLRI Type=3)
4. IPv6 prefix NLRI (NLRI Type=4)

3/25
EOS-4.24.2 supports most of the BGP-LS TLVs in https://tools.ietf.org/html/draft-ietf-idr-
rfc7752bis-06 and https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-18 that
are relevant for non multi-topology IS-IS on P2P links. The detailed list of supported and
unsupported TLVs are listed in the following sub-sections.

Fields common to all NLRI types

Field Description

Protocol- The following protocol-IDs are supported in EOS-4.24.2

id
1 IS-IS Level 1

2 IS-IS Level 2

All other protocol-IDs are NOT supported.

Identifier The identifier field is used to disambiguate different instances of the IGP. IS-IS
implementation in EOS-4.24.2 does not have multi instance support. As a
result this field is set to 0 by default as recommended by draft-ietf-idr-
rfc7752bis in the case of a single IGP instance. The “identifier” in the “isis
instance” command can be used to set the identifier to a different value as
described in the configuration CLI section.

Starting in EOS-4.26.1, IS-IS supports multiple instances. The Identifier is set

to the IS-IS instance-id by default, either 0 for default IS-IS instance or non-
zero specified using ‘instance-id’ when configuring router isis <instance>
instance-id <id>. Additionally the “identifier” in the “isis instance” command
under router bgp mode -> address-family link-state can be used to override the
identifieradvertised in BGP-LS advertisements.

Node NLRI

Node NLRIs are made up of

Protocol-ID (shown above)

Identifier (shown above)
Local Node Descriptor (TLV Type=256)

Node Descriptor

A node descriptor uniquely identifies an IGP node in the IGP topology. For a more detailed
discussion on node descriptors, please refer to https://tools.ietf.org/html/draft-ietf-idr-
rfc7752bis-06#section-4.2.1

4/25
EOS-4.24.2 supports the following TLVs in the local and remote node descriptors

Table 1 – Supported Node TLVs

Field Type Description / Source of content

Autonomous 512 Value of the ASN of the BGP instance of the node which is
System originating the BGP-LS updates.

BGP-LS 513 Set to 0 always for compatibility with older BGP-LS

Identifier implementations. (deprecated in draft-ietf-idr-rfc7752bis). The
“identifier” in the “isis instance” CLI has NO effect on the contents
of this TLV.

IGP Router- 515 For IS-IS non-pseudonode, this contains the 6-octet ISO System ID.
ID
For IS-IS pseudonode, this contains the 6-octet ISO System ID of
the DIS followed by the 1-octet, non zero PSN identifier

The following TLVs are NOT supported in EOS-4.24.2

OSPF Area-ID (TLV Type 514)

Link NLRI

The LINK NLRI carries information about a unidirectional link in the IGP topology, ie, for a
link A—B between 2 nodes A and B, there are 2 “half links” A->B and B->A (thus 2 link
NLRIs) in BGP-LS.

2-way connectivity check

EOS implements the optional 2-way connectivity check mentioned in section 4.2.2 of draft-
ietf-idr-rfc7752bis. EOS ensures that link NLRI advertisements for ‘broken’ half links are NOT
advertised to a BGP-LS peer. What this means for example is that for a given link A–B, if A’s
LSP listing B as a neighbor is present in the producer’s IS-IS LSDB, but B’s LSP isn’t (or B’s
LSP is present but doesn’t list A as a neighbor), neither A->B nor B->A link NLRIs are
created in the producer’s Adj-Rib-in. When B’s LSP is updated/added listing A as a neighbor,
at that point both A->B and B->A link NLRIs are created in the producer’s Adj-Rib-in and
subsequently advertised to the BGP-LS peers. This also means that if there’s an update (to
the IS-IS LSDB) to A’s LSP removing B as neighbor (or A’s LSP is removed), or there’s an
update to B’s LSP removing A as neighbor (or B’s LSP is removed), BGP-LS will delete both
A->B and B->A link NLRIs from its Adj-Rib-in and subsequently withdraw both BGP paths.

Link NLRIs are made up of

Protocol-ID (shown above)

Identifier (shown above)

5/25
 Local Node Descriptor (shown above)
Remote Node Descriptor (shown above)
Link Descriptor

Link Descriptor

The link descriptor is represented as a set of TLVs and is used to uniquely identify a half link
to the peering router in the presence of multiple links between 2 nodes. The link descriptor is
empty in the absence of traffic engineering in IS-IS. Please see section “BGP-LS
advertisement of IS-IS link NLRI when traffic-engineering is not enabled” for details.

Table-2 Supported Link Descriptor TLVs

Field Type Description

IPv4 259 Contents of TLV 22/sub type 6 defined in RFC5305 specifying the 4
interface octet ipv4 addresses configured locally on the link.
address

Ipv4 260 Contents of TLV 22/sub type 8 defined in RFC5305 specifying the 4
neighbor octet ipv4 addresses configured on the neighbor for that link.
address

IPv6 261 Contents of TLV 22/sub type 12 defined in RFC6119 containing the
interface 16 octet ipv6 addresses configured locally on the link
address

Ipv6 262 Contents of TLV 22/sub type 13 defined in RFC6119 containing the
neighbor 16 octet ipv4 addresses configured on the neighbor for that link.
address

The following Link Descriptor TLVs are not supported in EOS-4.24.2

Link Local/Remote Identifiers (TLV Type 258)

Multi-Topology identifier (TLV Type 263)

Prefix NLRI

IPv4 and IPv6 prefix NLRIs are made up of

Protocol-ID (shown above)

Identifier (shown above)
Node Descriptor (shown above)
Prefix Descriptor

Prefix Descriptor

6/25
The prefix descriptor contains IPv4/6 reachability information. Table-3 lists the supported
TLVs.

Table-3 List of supported Prefix Descriptor TLVs

Field TLV# Description / Source of content

IP reachability 265 Source is TLV 135 for IPv4 and TLV 236 for IPv6.
information
Sourcing from Multi-topology TLV 235, TLV 237 is not
supported in EOS-4.24.2

The following TLVs are not supported in EOS-4.24.2

Multi-Topology identifier (TLV 263)

OSPF route type (TLV 264)

BGP-LS path attribute

BGP-LS attribute is an optional non-transitive BGP path attribute that carries information
about the node, link or the prefix in the IGP topology. The attribute is specified as a set of
TLVs.

In theory, the BGP-LS attribute can be large enough to cause the BGP update message to
exceed the maximum message size of 4096 octets. EOS will never advertise a BGP-LS
update message exceeding the maximum message. EOS does NOT support RFC8654
Extended Message Support for BGP.

In EOS-4.24.2, we do not anticipate that the supported TLVs can cause a single BGP-LS
NLRI (with the BGP-LS path attribute) to exceed the BGP update message size of 4096
octets. However if it does happen, the BGP-LS update will be dropped and not sent to the
peer.

EOS does NOT order TLVs within the BGP-LS attribute. This is inline with
https://tools.ietf.org/html/draft-ietf-idr-rfc7752bis-06#section-4.1

“The TLVs within the BGP-LS Attribute MAY be ordered in ascending order by TLV type.
BGP-LS Attribute with unordered TLVs MUST NOT be consider malformed.”

Node Attribute

A node attribute is sent as the BGP-LS path attribute with a node NLRI and contains
properties or additional information about the node.

Table-4 : List of supported node attribute TLVs

7/25
 TLV
Field # Description

Node Flag Bits 1024 This is a TLV containing a variable length bit array representing
the following flags

Overload Bit

Attached Bit

The below flags are OSPF specific and NOT supported in EOS-
4.24.2

External Bit

ABR Bit

Router Bit

V6 Bit

Node Name 1026 Contents of TLV 137 as defined in RFC5301

IS-IS Area 1027 Contents of TLV 1 (area address) in the IS-IS LSP
Identifier

IPv4 Router-ID 1028 Contents of TLV 134 in the LSP specifying the local node’s ipv4
of Local Node TE router id. (requires IS-IS traffic engineering to be enabled)

IPv6 Router-ID 1029 Contents of TLV 140 in the LSP specifying the local node’s ipv6
of Local Node TE router id.

(requires IS-IS traffic engineering to be enabled)

The TLVs below carry segment routing information

SID/Label TLV 1161 Used as a sub tlv in some of the other SR TLVs listed below

SR Capabilities 1034 Contents of TLV 242’s sub TLV 2

(includes
SRGB)

SRLB 1036 Contents of TLV 242’s sub TLV 22

The following TLVs are not supported in EOS-4.24.2

SRMS Preference (TLV 1037)

Multi-Topology Identifier (TLV 263)
Opaque Node attribute (TLV 1025)
SR algorithm (TLV 1035)

8/25
Link Attribute

A link attribute is sent as the BGP-LS path attribute with a link NLRI and contains properties
or additional information about the half link.

Table-5 : List of supported link attribute TLVs

Field TLV# Description/Source of information in IS-IS

IPv4 router-id of local 1028 Contents of TLV 134 in the LSP specifying the local
node node’s ipv4 TE router id

IPv6 router-id of local 1029 Contents of TLV 140 in the LSP specifying the local
node node’s ipv6 TE router id

IPv4 router-id of 1030 Contents of TLV 134 in the LSP specifying the remote
remote node node’s ipv4 TE router id

IPv6 router-id of 1031 Contents of TLV 140 in the LSP specifying the remote
remote node node’s ipv6 TE router id

Administrative group 1088 TLV 22’s sub TLV 3

(color)

Maximum link 1089 TLV 22’s sub TLV 9

bandwidth

Max. reservable link 1090 TLV 22’s sub TLV 10

bandwidth

Unreserved bandwidth 1091 TLV 22’s sub TLV 11

TE default metric 1092 TLV 22’s sub TLV 18

IGP metric 1095 “3 bytes default metric” in TLV 22

Shared risk link group 1096 IPv4 SRLG is TLV 138

IPv6 SRLG is TLV 139

The TLV below carries segment routing information

SR Adj SID 1099 sub TLV 31 in TLV 22 in EOS-4.24.2

sub TLV 31 in TLV 222 is not supported in EOS-4.24.2

sub TLV 31 in TLVs 23, 223 not supported in EOS-

4.24.2

The following TLVs are not supported

9/25
 Link protection type (TLV 1093)
MPLS protocol mask (TLV 1094)
Opaque link attribute (TLV 1097)
Link name (TLV 1098)
SR LAN Adj SID (TLV 1100)
L2 Bundle member (TLV 1172)

Prefix Attribute

A prefix attribute is sent as the BGP-LS path attribute with a IPv4 or IPv6 prefix NLRI and
contains properties or additional information about the prefix.

Table-6 : List of supported prefix attribute TLVs

Field TLV# Description

IGP Flags 1152 Only ‘D’ bit relevant for IS-IS

Pick up/down bit from TLV135 for IPv4, and from TLV236 for IPv6.

Sourcing from TLVs 235, 237(multi-topology) is not supported in

EOS-4.24.2

Prefix 1155 Metric value in TLV 135 for IPv4, 236 for IPv6
Metric
Sourcing from TLVs 235, 237(multi-topology) is not supported in
EOS-4.24.2

The TLV below carries segment routing information

SR Prefix 1158 sub TLV 3 of TLVs 135, 236

SID
Sourcing from TLVs 235, 237 (multi-topology) is not supported in
EOS-4.24.2

The following TLVs are not supported:

IGP Route tag (TLV 1153)

IGP Extended Route tag (TLV 1154)

OSPF Forwarding address (TLV 1156)
Opaque Prefix attribute (TLV 1157)
Prefix Attribute Flags (TLV 1170)
Source Router-ID (TLV 1171)
SR Range (TLV 1159)

10/25
BGP-LS advertisement of IS-IS link NLRI when traffic-engineering is not
enabled
A BGP-LS link state NLRI half-link is identified by a 3-tuple of

local node descriptor

remote node descriptor
link descriptor

The contents of the link descriptor are the IPv4 and/or IPv6 local and remote interface
addresses which are present in sub TLVs 6, 8(v4 local, remote) and sub TLVs 12, 13 (v6
local, remote) of TLV 22 which contains the neighbor information. As specified in RFC5305,
(and the IPv6 equivalent RFC6119) it’s optional for an IS-IS speaker to originate these sub-
TLVs in the absence of traffic engineering.

This implies that the link descriptor will be empty in the absence of these sub-TLVs, which is
a problem when there are multiple point-to-point links between the same pair of nodes; since
the link state NLRIs generated for the links will be the same and the BGP-LS consumer will
only receive one link state NLRI with an empty link descriptor TLV. It is the operator’s
responsibility to ensure that the required IS-IS configuration is present to originate these sub
TLVs to avoid this problem. Typically this will require enabling traffic engineering within IS-IS
as well as on the corresponding interfaces. In most deployments of BGP-LS we expect that
BGP-LS is used as a means of communicating the IGP topology to a controller for the
purpose of setting up traffic engineered paths. Therefore traffic engineering in IS-IS would
already be enabled. If the use case does not require traffic engineering, it’s usually a small
configuration overhead to enable traffic engineering and seems like a sensible tradeoff to
avoid incorrect information in BGP-LS

EOS’ IS-IS implementation does not originate these sub-TLVs in the absence of traffic
engineering configuration. The following configuration enables traffic engineering in IS-IS in
EOS, which will generate the required sub TLVs. (Note only the delta configuration required
to enable TE is shown, to enable IS-IS itself configuration like “net” are required).

router general
router-id ipv4 100.100.100.1
! only needed for ipv6 TE
router-id ipv6 5000::1
!
router traffic-engineering
!
router isis instanceName
traffic-engineering
no shutdown
!
interface Ethernet1
! needs to be enabled on each IS-IS enabled interface
traffic-engineering

11/25
BGP-LS Tx Update generation rate as propagator
1. The Bgp agent in EOS reacts to a change in the IGP topology (an LSP update in the
case of IS-IS) and asynchronously generates the needed BGP-LS updates as a result
of the change. Thus EOS does NOT guarantee how quickly a topology change is
discovered by the controller/consumer from the time it is reflected in the IGP on the
producer node.
2. As a corollary, EOS does NOT throttle updates towards the controller to within a
maximum rate of updates per unit time. It is assumed that the
controller/consumer/propagator can handle updates being generated at a rate that is
purely a function of the rate of churn in the IGP.
3. No knobs are provided to control the update generation rate.

Behavior on reception of BGP-LS Updates

EOS-4.24.2 supports only the producer role for BGP-LS. As a producer EOS only generates
updates towards its peers. In other words, BGP-LS producer is a transmit only feature and
there’s no support for receiving and accepting BGP-LS updates from peers. It is expected
that as a producer, EOS will peer with route reflectors (BGP-LS propagators) or consumers.
In such peerings it’s expected that the peer (propagator/consumer) doesn’t send any
updates towards the producer. However for any reason, if the peer sends an EOS device
BGP-LS updates, the received BGP-LS NLRIs are ignored by the EOS device and are not
stored in the Adj-Rib-in. It is recommended that an outbound route-map to deny all BGP-LS
updates towards EOS BGP-LS producers is applied on the peer.

BGP Additional Paths (Add-Path)

RFC7911 specifies support for sending multiple BGP paths for the same NLRI. There’s no
support for additional path transmit (add-path-tx) for the BGP-LS AFI/SAFI. As a producer
there’s only one BGP path per NLRI, so it’s not possible to support additional paths. The add
path capability for transmit isn’t advertised by EOS for BGP-LS AFI/SAFI.

EOS by default advertises additional paths in the receive direction and is thus done also for
BGP-LS. However, since there’s no support for receive functionality for BGP-LS AFI/SAFI,
the capability advertisement is meaningless and has no effect on EOS behavior for BGP-LS
AFI/SAFI.

BGP-LS advertisement of unreachable nodes

EOS-4.24.2 does NOT use the IGP SPF computation results to detect unreachable nodes in
the topology and use that information to disregard LSPs information of unreachable nodes.
This would mean that it is possible in certain scenarios for a BGP-LS consumer to receive LS
updates based on stale LSPs. One such scenario is discussed in section-4.7 of the BGP-LS
draft (slides from IETF meeting).

12/25
Inbound route-map
As there’s no support for receive functionality for BGP-LS, there’s no support for inbound
route-maps for BGP-LS AFI/SAFI.

Outbound route-map
There is no support for a BGP-LS AFI/SAFI specific route-map configuration. However a
route-map configured under ‘router bgp’ mode and applied in the outbound direction to a
BGP-LS peer will take effect. Note that only existing match and set criteria are supported and
no new criteria for the BGP-LS path attribute will be added. Per prefix criteria also obviously
do not take effect since BGP-LS NLRIs aren’t prefixes.

“bgp missing-policy action” interaction

There are 2 aspects

1. interaction/support for “bgp missing-policy address-family all”

2. AFI/SAFI specific “bgp missing-policy action”

For both 1. and 2. in EOS-4.24.2 “direction out” (tx) is supported.

“direction in” (rx) is NOT supported but the AFI/SAFI specific CLI “bgp missing-policy action”
CLI is visible and has no effect.

Given that there’s no support for “neighbor <PEER_ADDRESS> route-map

<ROUTE_MAP_NAME> out” under “address-family link-state” in EOS-4.24.2; if there’s
“bgp missing-policy address-family all direction out action deny” configured, then “bgp
missing-policy direction out action permit” is required to override the global config to
allow BGP-LS producer updates to be sent to peers in the absence of an outbound route-
map.

BGP-LS behavior on Isis agent restart

In EOS-4.24.2, when the Isis agent restarts, BGP-LS will withdraw and re-advertise all BGP-
LS NLRIs.

Platform Compatibility
BGP-LS is a platform independent feature and is supported on all platforms on which
BGP and IS-IS are supported in EOS.
BGP-LS in multi-instance mode is supported only on those platforms which support
BGP along with multi-instance IS-IS. Refer to TOI on IS-IS multiple instances for more
info.

13/25
Configuration

Configuring BGP-LS on a BGP peer

router bgp 1
neighbor <PEER_ADDRESS> remote-as <REMOTE_ASN>
address-family link-state
neighbor PEER_ADDRESS activate

The above configuration enables BGP-LS AFI/SAFI for a particular peer. This is done
as specified in [RFC4760], by using capability code 1 (multi-protocol BGP), with AFI
16388 / SAFI 71 for BGP-LS.
The new AFI/SAFI can be configured for IPv4, IPv6, IPv6 link local BGP peers under
the default VRF only.

Configuring import of IS-IS LSDB into BGP

router bgp 1

address-family link-state

isis instance <IS-IS_INSTANCE_NAME> [identifier <0 - U64MAX>]

The mandatory “IS-IS_INSTANCE_NAME” argument specifies which IS-IS instance to

import (needs to match the IS-IS instance configured in DEFAULT_VRF using “router
isis” cli)
The optional “identifier” argument specifies what BGP-LS populates in the “Identifier”
field in the BGP-LS NLRIs. (The Identifier field in the NLRI is used to disambiguate
NLRIs when there are multiple IGP instances). If no “identifier” is specified in the CLI,
BGP-LS will use the instance-ID of the IS-IS instance. The default IS-IS instance id is
0, thus the default value for identifier is 0. This keyword has no effect on the
deprecated TLV 513 – BGP-LS identifier in local and remote node descriptors.
All IS-IS levels in the specified IS-IS instance are imported into BGP-LS.

Examples:

Identifier in
IS-IS config Import config What is imported BGP-LS

router isis foo isis bar nothing (IS-IS instance not N/A
present)

router isis foovrf isis foovrf nothing (no instance in N/A

vrf vrf1 default vrf)

14/25
 router isis isis instance0 Levels 1,2 of IS-IS instance 0
instance0 “instance0”.

is-type level-1-2

router isis isis instance0 Level 1 of IS-IS instance 1000

instance0 identifier 1000 “instance0”

is-type level-1

Following examples only apply starting in EOS-4.26.1 with multi-instance IS-IS support:

Identifier in
IS-IS config Import config What is imported BGP-LS

router isis instance0 isis instance0 Levels 1,2 of IS-IS instances instance0 ->
router isis instance1 isis instance1 “instance0” and “instance1” 0
instance-id 1000 instance0 status: Active instance1 ->
instance1 status: Active 1000

router isis instance0 isis instance0 Levels 1,2 of IS-IS instances instance0 ->
router isis instance1 isis instance1 “instance0” and “instance1” 0
instance-id 1000 identifier 2000 instance0 status: Active instance1 ->
instance1 status: Active 2000

router isis instance0 isis instance0 Levels 1,2 of IS-IS instances instance0 ->
router isis instance1 identifier 1000 “instance0” and “instance1” 1000
instance-id 1000 isis instance1 instance0 status: Active instance1 ->
identifier 2000 instance1 status: Active 2000

router isis instance0 isis instance0 Levels 1,2 of IS-IS instance Instance0 ->
(missing router isis isis instance1 “instance0” 0
instance1 config) identifier 2000 instance0 status: Active (instance1
instance1 status: IGP instance not imported)
not active

router isis instance0 isis instance0 Levels 1,2 of IS-IS instance instance0 ->
router isis instance1 identifier 1000 “instance0” 1000
instance-id 1000 isis instance1 instance0 status: Active (instance1
instance1 status: Conflicting not imported)
identifier

Show Commands
In EOS-4.24.2, the following new commands specific to BGP-LS have been added:

show bgp link-state summary

15/25
 show bgp link-state [node | ink | ipv4-prefix | ipv6-prefix] |
[detail]
show bgp neighbor <PEER_ADDRESS> link-state advertised-routes [node |
link | ipv4-prefix | ipv6-prefix]

All of the above commands are eAPI enabled.

Note that:

1. Both show bgp link-state … and show bgp neighbor <> link-state advertised-routes do
NOT have an option to filter by a specific NLRI.
2. For show bgp neighbor <> link-state advertised-routes, there’s no detail option

The following commands have been added for debugging,

show tech-support bgp link-state

show tech-support extended bgp link-state

show bgp link-state summary

switch#show bgp link-state summary

BGP summary information for VRF default
Router identifier 10.0.0.102, local AS number 64513
Neighbor Status Codes: m - Under maintenance
Neighbor V AS MsgRcvd MsgSent InQ OutQ Up/Down State
10.1.0.100 4 64496 20 1083 0 0 00:04:04 Estab
2001:DB8::1 4 64510 20 1079 0 0 00:04:14 Estab

show bgp link-state [node | link | ipv4-prefix | ipv6-prefix]

16/25
switch# sh bgp link-state
BGP routing table information for VRF default
Router identifier 10.0.0.1, local AS number 64513
BRIB status codes: * - valid, > - active
NLRI codes: Proto - IGP Protocol
I L1 - IS-IS Level-1, I L2 - IS-IS Level-2
ID - Identifier (IGP Instance ID)
RRID - Remote Node IGP Router ID

Type Proto ID IGP Router ID NLRI Specific

---- ----- --- --------------- -----------------------
*> node I L1 0 1111.1111.1001 -
*> node I L1 232 1111.1111.1003 -
*> link I L1 0 1111.1111.1001 RRID: 1111.1111.1002
Addresses: Local [1.0.0.1, 2000:0:0:40::1] Neighbor [1.0.0.2, 2000:0:0:40::2]
*> link I L1 0 1111.1111.1002 RRID: 1111.1111.1001
Addresses: Local [1.0.0.2, 2000:0:0:40::2] Neighbor [1.0.0.1, 2000:0:0:40::1]
*> prefix I L1 0 1111.1111.1001 IPv4 prefix: 1.0.0.0/24
*> prefix I L1 232 1111.1111.1003 IPv4 prefix: 1.0.1.0/24
*> prefix I L1 0 1111.1111.1002 IPv6 prefix: 2000:0:0:40::/64
*> prefix I L1 232 1111.1111.1003 IPv6 prefix: 2000:0:0:41::/64

1. Some fields common to most BGP AFI/SAFIs like “next hop”, “metric”, “local Pref”,
“weight”, “path” (as path) are not shown because
Those fields will not change for a producer and aren’t as important as the fields
from the NLRI.
Adding them makes the CLI output cluttered and distracts from the information
that is relevant/important.
2. The ASN which is part of the NLRI isn’t shown as it’s the producer’s ASN and is the
same for all NLRIs.
3. The LRID and RRID fields for IS-IS are IS-IS system IDs or system ID + LAN ID.
4. Note that the Link NLRI is split into 2 lines
5. The optional filters will filter the output based on the NLRI type. There’s no change to
the output format

17/25
 6. The ordering of the NLRIs is as follows:
First sorted by NLRI type ie, all nodes, followed by all links, followed by all ipv4
prefixes, followed by all ipv6 prefixes
Then by IS-IS level ie, all IS-IS Level1 NLRIs followed by all IS-IS level2 NLRIs.
(Note that inside BGP-LS each IS-IS level is a separate protocol). So in effect
sorted by protocol.
Then the IGP instance ID (identifier)
Within each NLRI type, sorted by the fields of the NLRI
For Node NLRI it’s the igp router ID
For Link NLRI sort order is :
Local node descriptor’s IGP router-ID
Local node descriptor’s ASN (not shown, same for all NLRIs)
Remote node descriptor’s IGP router-ID
Remote node descriptor’s ASN
Local ipv4 address(es)
Local Ipv4 address(es)
Local ipv6 address(es)
Remote ipv6 address(es)
For prefix NLRIs, sort order is:
node descriptor’s IGP router-ID
node descriptor’s ASN (not shown, same for all NLRIs)
Prefix

show bgp link-state [node | link | ipv4-prefix | ipv6-prefix ] detail

Note that we’re showing each nlri type command separately for ease of description and
showing only one NLRI. Multiple NLRIs will be printed in the same order as specified in
show bgp link-state
If “show bgp link-state detail” is issued we’ll print all the nlri types in the order specified
in “show bgp link-state”

show bgp link-state node detail

18/25
switch#sh bgp link-state node detail
BGP routing table information for VRF default
Router identifier 10.0.0.1, local AS number 64513
BGP routing table entry for Node: IS-IS Level-1, Identifier: 0, ASN: 64513
Router ID: 1111.2222.3333 (rtrA)
Paths: 1 available
Local
- from - (10.0.0.1)
Origin INCOMPLETE, metric 0, localpref 0, IGP metric 1, weight -, received
00:00:21 ago, valid, local, best, imported (IS-IS)
IPv4 router ID: 2.2.2.2
IPv6 router ID: 200::1
Area address: 49.0001
Flags: [Overloaded, Attached]
SR Capability: Flags: [I V]
SRGB Base: 900000 Range: 65536
SR Local Block:
SRLB Base: 965536 Range: 65536

The text following the Router ID “(rtrA)” is the hostname and will be printed if present in
the BGP-LS path attribute.

show bgp neighbor <PEER_ADDRESS> link-state advertised-routes

The command output is similar to ‘show bgp link-state’

show bgp link-state link detail

19/25
switch#sh bgp link-state link detail
BGP routing table information for VRF default
Router identifier 10.0.0.1, local AS number 64513
BGP routing table entry for Link: IS-IS Level-1, Identifier: 0, ASN: 64513
Local node router ID: 1111.1111.1001.01, Remote node router ID: 1111.1111.1000
IPv4 interface address: 10.0.0.1
IPv4 neighbor address: 10.0.0.2
IPv6 interface address: 2001:DB8::1
IPv6 neighbor address: 2001:DB8::2
Paths: 1 available
Local
- from - (10.0.0.1)
Origin INCOMPLETE, metric 0, localpref 0, IGP metric 1, weight -, received
00:00:21 ago, valid, local, best, imported (IS-IS)
Local node IPv4 router ID: 1.0.0.2
Local node IPv6 router ID: 2001:DB8::1
Remote node IPv4 router ID: 2.0.0.2
Remote node IPv6 router ID: 2001:DB8::2
IGP metric: 10
TE default metric: 7
Administrative group (Color): 0x1
Maximum link BW: 10.0 Mbps
Maximum reservable link BW: 5.00 Mbps
Unreserved BW:
TE class 0: 5.00 Mbps TE class 1: 5.00 Mbps TE class 2: 5.00 Mbps
TE class 3: 5.00 Mbps TE class 4: 5.00 Mbps TE class 5: 5.00 Mbps
TE class 6: 5.00 Mbps TE class 7: 5.00 Mbps
Shared Risk Link Group:
Group ID: 30
Group ID: 40
SR Adjacency-SID: 1 flags: [] weight: 0x0
SR Adjacency-SID: 965539 flags: [L V] weight: 0x0

show bgp link-state ipv4-prefix detail

switch#sh bgp link-state ipv4-prefix detail

BGP routing table information for VRF default
Router identifier 10.0.0.1, local AS number 64513
BGP routing table entry for Prefix: IS-IS Level-1, Identifier: 0, ASN: 64513
Router ID: 1111.1111.1001, Prefix: 10.1.2.0/24
Paths: 1 available
Local
- from - (10.0.0.1)
Origin INCOMPLETE, metric 0, localpref 0, IGP metric 1, weight -, received
00:00:21 ago, valid, local, best, imported (IS-IS)
Metric: 10
Flags: [IS-IS Down]
SR Prefix-SID: 10 Flags: [N] Algorithm: 0

show bgp link-state ipv6-prefix detail

20/25
switch#sh bgp link-state ipv4-prefix detail
BGP routing table information for VRF default
Router identifier 10.0.0.1, local AS number 64513
BGP routing table entry for Prefix: IS-IS Level-1, Identifier: 0, ASN: 64513
Router ID: 1111.1111.1001, Prefix: 2001:DB8::1/64
Paths: 1 available
Local
- from - (10.0.0.1)
Origin INCOMPLETE, metric 0, localpref 0, IGP metric 1, weight -, received
00:00:21 ago, valid, local, best, imported (IS-IS)
Metric: 10
Flags: [IS-IS Down]
SR Prefix-SID: 10 Flags: [N] Algorithm: 0

show tech-support bgp link-state

This command shows the internal state of BGP-LS specific data structures. This
command is recommended to be used only under Arista TAC supervision. It MUST
NOT be run as part of periodic tech-support collection.
The sample output is not shown as it’s subject to change

show tech-support extended bgp link-state

This has the subset of support commands that are relevant to BGP-LS. In EOS-4.24.2 this
includes

show isis neighbors detail

show isis database traffic-engineering
show bgp link-state summary
show bgp link-state detail

Note that new BGP-LS specific CLIs have not been added to the existing ‘show tech-
support’ list of commands to avoid adding even more commands to it.

Changes to existing show commands

show <ip | ipv6> bgp neighbors [PEER_ADDR]

21/25
Arista# show ip bgp neighbors 10.0.0.2
BGP version 4, remote router ID 10.0.0.2, VRF default
Negotiated BGP version 4
...
Neighbor Capabilities:
Multiprotocol IPv4 Unicast: advertised and received and negotiated
Multiprotocol Link State: advertised and received and negotiated
...
Prefix Statistics:
Sent Rcvd
IPv4 Unicast: 0 0
IPv6 Unicast: 0 0
Link State: 1 0

show ip bgp peer-group <PEER_GROUP_NAME>

BGP peer-group is pg, remote AS 1, peer-group internal

BGP version 4
Static peer-group members:
VRF default:
10.0.0.2, state: Connect
Negotiated MP Capabilities:
IPv4 Unicast: Yes
IPv4 Multicast: No
...
Link State: Yes

show bgp instance

Arista# show bgp instance

BGP instance information for VRF default
BGP Local AS: 10, Router ID: 10.0.0.1
...
Address family Link State :
Additional-paths installation is disabled
Convergence based update synchronization is disabled
Role(s): Producer
Imported LinkState Database(s):
Source: IS-IS, VRF: default, Instance: inst1
Producer Stats:
Num nodes: 2
Num links: 2
Num IPv4 prefixes: 4
Num IPv6 prefixes: 5

Starting in EOS-4.26.1, show bgp instance also provides information about the current status
of IS-IS instances that are imported into BGP-LS as shown in bold below:

22/25
Arista# show bgp instance
BGP instance information for VRF default

BGP Local AS: 10, Router ID: 10.0.0.1

...
Address family Link State :
Additional-paths installation is disabled
Convergence based update synchronization is disabled
Role(s): Producer
Imported LinkState Database(s):
Source: IS-IS, VRF: default, Instance: instance0, Status: Active
Source: IS-IS, VRF: default, Instance: instance1, Status: IGP instance not active
Source: IS-IS, VRF: default, Instance: instance2, Status: Conflicting identifier
Source: IS-IS, VRF: default, Instance: instance3, Status: Active
Producer Stats:
Num nodes: 2
Num links: 2
Num IPv4 prefixes: 4
Num IPv6 prefixes: 5

Syslog Messages
Starting in EOS-4.26.1, following syslog will be generated on encountering a conflicting
identifier:

'%BGP-4-LS_CONFLICTING_ID_FOR_MULTIPLE_INSTANCES: BGP Link State cannot be

enabled on IS-IS instance instance2 due to conflicting identifier on instance0'

Troubleshooting
The BGP-LS specific output of ‘show bgp instance’ provides a quick summary of the
IS-IS instances that are imported, the count of the number of BGP-LS paths, and
information about any IS-IS instances that are not imported due to an error like
conflicting identifiers.
‘show bgp link-state summary’ can be used to get the list of BGP-LS peers.
To debug peering issues, ‘show bgp neighbor [PEER_ADDRESS]’ can be used to
see the advertised, received and negotiated capabilities.
To see the BGP-LS BRIB created from the IS-IS LSDB, ‘show bgp link-state [detail]
[NLRI_TYPE]’ can be used. The output of ‘show isis database traffic-engineering
[LSP_ID] [level]’ can be used to see the contents of the IS-IS LSDB.
If some BGP-LS state is unexpected (either missing, incorrect, or extraneous), it’s
useful to check the IS-IS LSDB to see what the IS-IS state is. In steady state, the
BGP-LS BRIB and IS-IS database will be in sync.
To see what BGP-LS paths have been advertised to the BGP-LS peer(s), ‘show bgp
neighbor <PEER_ADDRESS> link-state advertised-routes’ can be used.
BGP-LS functionality is implemented by the Bgp agent, so the agent traces are present
in /var/log/agents/Bgp*
BGP-LS quicktraces are present in /var/log/qt/Bgp*.qt

23/25
Collecting Information for Problem Reporting

While reporting a problem it’s helpful to have the following information:

The output of show tech-support bgp link-state
The output of show tech-support extended bgp link-state
The output of show tech-support
The output of show tech-support isis
The contents of /var/log/agents
The contents of /var/log/qt

The show commands listed above tend to generate large volumes of text, so redirecting
them and sharing the files with Arista TAC is recommended.

If there’s an agent crash, then the core file(s) is usually required to be able to effectively
debug the problem and provide a root cause.

Tracing
Disclaimer: In some cases, enabling tracing can seriously impact the performance of the
switch. Please use it cautiously and seek advice from an Arista representative before
enabling this in any production environments.

The trace facility ‘linkStatePlugin’ has the BGP-LS specific traces and can be enabled
using ‘trace Bgp enable LinkStatePlugin all’

Limitations
BGP-LS propagator and consumer roles aren’t supported, ie., there’s no BGP receive
side functionality.
Only IS-IS LSDB can be imported into BGP-LS. (There’s no support for example for
importing OSPFv2, OSPFv3 LSDB into BGP-LS).
For IS-IS LSDB import there’s no support for
Multi-topology IS-IS.
LAN adjacencies (broadcast links) in IS-IS.
The BGP-LS NLRI and BGP-LS Path attribute sections have detailed lists of
supported and unsupported TLVs.
EOS does not support BGP update messages greater than 4096 octets. Thus any
single BGP-LS path and its attributes has to fit within 4096 octets. The BGP-LS path
attribute section has more details about this.
Hitless restart of Bgp agent is not supported.

24/25
 When Isis agent restarts all BGP-LS NLRIs are withdrawn and they’re re-advertised
when they’re relearnt in IS-IS.
For link NLRIs the 2-way connectivity check assumes that the link descriptors are
symmetric, for example, if there’s a half link with link descriptor { local IPv4 address :
10.0.0.1, remote IPv4 address : 10.0.0.2 }, the corresponding remote half link’s link
descriptor should be { local IPv4 address : 10.0.0.2, remote IPv4 address : 10.0.0.1 }.

Resources
Distribution of Link-State and Traffic Engineering Information Using BGP – draft-ietf-idr-
rfc7752bis-06
BGP Link-State extensions for Segment Routing – draft-ietf-idr-bgp-ls-segment-routing-
ext-18
RFC5305 IS-IS Extensions for Traffic Engineering
RFC6119 IPv6 Traffic Engineering in IS-IS
RFC8667 IS-IS Extensions for Segment Routing

25/25