Just like with the other routing protocols such as OSPF or EIGRP, BGP speaking routers first need to become neighbors prior to exchanging routing information. However, in case of BGP, neighbor adjacency is configured manually, putting a neighbor IP address and ASN into the BGP configuration. A new initiative reflected in the BGP Logical Link Discovery Protocol (LLDP) Peer Discovery IETF Internet draft could change the status quo in the future, allowing the BGP adjacency on the point-to-point links to be established automatically, using the LLDP protocol.
Link Layer Discovery Protocol (LLDP) is a vendor-neutral industry standard link layer protocol defined in IEEE 802.1AB. It is intended to replace proprietary Cisco Discovery Protocol (CDP). Thanks to LLDP, network devices such as switches operating on Layer 2 (Link layer) of OSI model can collect upper layer information of neighboring device, such as IP address, OS version etc. LLDP is a protocol for discovering neighbors and cannot be used for configuring network devices.
Every LLDP Ethernet frame contains one LLDP Data Unit (LLDPDU) with Ethernet type set to 0x88CC. The router sends the LLDP advertisements out of its ports every 30 seconds by default. The source (SA) MAC address is the router MAC address and the destination address (DA) is LLDP multicast address 01-80-C2-00-00-0E. The received LLDP Ethernet frame is not forwarded to the other devices.
Picture 1 – Structure of the Ethernet LLDP Frame
The LLDP Data Unit carried inside Ethernet frame contains several different Type Length Values (TLVs) structures. A router sends LLDPDU with different TLVs to inform a neighbor device about local information. Some TLVs are mandatory, others are optional. For instance, mandatory TLVs inside every LLDPU are Chassis ID (Type 1), TLV Port ID (Type 2), Time to Live (TTL) (Type 3) and End of LLDPDU (Type 0). The chassis ID and port ID TLVs are used for router identification. The Time to Live is used for aging purpose and informing on how long a receiver must keep the LLDP advertisement. The default value of 120 seconds can be changed with lldp holdtime command. The End of LLDPDU identifies the end of the LLDPDU.
| NOTE: In TLV, T is information type, L is information length and V is value (TLV content). |
One of the optional TLVs type are the Organizationally Specific TLVs (OS-TLVs). They all share the common type value of 127. The organizations are identified by the Organizationally Unique Identifier (OUI). For instance, IANA has assigned OUI 00-00-5E. Each organization defines its own OS-TLVs that are identified by Subtype.
The BGP Config OS-TLV is used for advertising the BGP configuration information. The OUI used for the BGP Config OS-TLV is 00-00-5E (IANA) and the subtype of the BGP Config OS-TLV is set to 1. The BGP configuration information inside BGP Config OS-TLV are composed of BGP Config Sub-TLVs. Each Sub-TLV carries specific BGP configuration information. For instance, BGP Local AS Sub-TLV contains 4-octet local Autonomous System (AS) number(s). All BGP Config Sub-TLVs contain Type and Length fields, with each of them being one octet long.
| NOTE: Multiple BGP Config OS-TLVs might be included in LLDPDU. |
Below is a structure of BGP Config OS-TLV encapsulated inside LLDPDU field of the Ethernet frame.
Picture 2 – BGP Config Organizationally Specific TLV
BGP Config Sub-TLVs are identified by their Sub-TLV type. For instance, BGP Local AS Sub-TLV has type set to 2. Another Sub-TLV – BGP Identifier Sub-TLV has type 3. The Table 1 below lists all known BGP Config TLVs along with their types.
| Name of BGP Config Sub-TLV | Type |
|---|---|
| Peering Address Sub-TLV | 1 |
| BGP Local AS Sub-TLV | 2 |
| BGP Identifier Sub-TLV | 3 |
| Session Group-ID Sub-TLV | 4 |
| BGP Session Capabilities Sub-TLV | 5 |
| Key Chain Sub-TLV | 6 |
Table 1 – BGP Config Sub-TLVs and Their Types
The meaning of the BGP Config Sub-TLVs and their operation is obvious. A router configured for LLDP peer discovery sends Peering Address Sub-TLV of the BGP Config TLV inside LLDPDU of the Ethernet frame. The advertisement informs a router on the opposite site of a link about the sender’s peering address. The distance might be one or two hops (when loopback address is used) and the address is either IPv4 or IPv6. A BGP receiver configured for for LLDP peer discovery tries to establish BGP session with the peer. The sending router might advertise its local AS number inside BGP Local AS Sub-TLV of the BGP OS-TLV. A second local ASN might also be included in case of an ASN migration. The sending router may also advertise its local BGP Identifier (BGP Router ID) in BGP Identifier Sub_TLV of the BGP-OS TLV where the BGP identifier is used for debugging purpose. A BGP speaking router might send Session Group-ID Sub-TLV to classify Top of Rack (ToR) or Spine BGP sessions in data centers. The sending router might send BGP Session Capabilities Sub-TLV of BGP-OS TLV to announce support for relevant capabilities such as MD5 authentication, TCP Authentication Option (TCP-AO) and The Generalized TTL Security Mechanism (GTSM). In this case the sender also sends Key Chain Sub-TLV of the BGP-OS TLV. It is a string (up to 64 octets) that specifies the key chain name.
BGP peering discovery using LLDP could be used in large Layer 3 data centers where eBGP is being used as a single routing protocol. Deployment of BGP with enabled BGP peering discovery using LLDP in large data centers in the future would significantly lower the BGP configuration overhead. The fact that the BGP neighbor discovery feature becomes an important challenge to solve is also indicated by the existence of another IEFT draft. This draft suggests another approach – changing the BGP itself. Instead of using other protocols such as LLDP, the draft introduces a new BGP Hello message. The message is sent in periodic time interval on the interfaces where BGP neighbor autodiscovery is enabled to the multicast IP address using UDP port 179. The hello message contains ASN of the sender along with TLVs that are composed of a connection peer address, router id etc.
The existence of two active IETF drafts discussing BGP neighbor auto-discovery proves the importance of this topic. The initial “BGP Neighbor Autodiscovery” draft first appeared in December, 2016, while the “BGP LLDP Peer Discovery” one in March of 2017. The drafts are far from being rolled out as both are still in the “I-D Exist” initial (default) state. The documents are not being tracked by the Internet Engineering Steering Group (IESG), since no request has been sent to the group yet. However, regardless of which draft will be implemented by vendors in the future, it is an indisputable fact that BGP peer discovery feature is a legitimate request.
Read this article in French – La découverte des peers BGP LLDP