The genesis of BGP was in 1989 when Kirk Lougheed, Len Bosack and Yakov Rekhter were sharing a meal at an IETF conference.

BGP neighbors, called peers, are established by manual configuration among routers to create a TCP session on port 179.

A BGP speaker sends 19-byte keep-alive messages every 30 seconds (protocol default value, tunable) to maintain the connection.

When it runs between different autonomous systems, it is called External BGP (eBGP or Exterior Border Gateway Protocol).

Other deployment topologies are also possible, such as running eBGP peering inside a VPN tunnel, allowing two remote sites to exchange routing information in a secure and isolated manner.

During the peering handshake, when OPEN messages are exchanged, BGP speakers can negotiate optional capabilities of the session,[10] including multiprotocol extensions[11] and various recovery modes.

Increasingly, BGP is used as a generalized signaling protocol to carry information about routes that may not be part of the global Internet, such as VPNs.

It is quite common, for example, to store the Adj-RIB-In, Adj-RIB-Out and the Loc-RIB together in the same data structure, with additional information attached to the RIB entries.

Next, for each neighbor, the BGP process applies various standard and implementation-dependent criteria to decide which routes conceptually should go into the Adj-RIB-In.

BGP communities are attribute tags that can be applied to incoming or outgoing prefixes to achieve some common goal.

[15] While it is common to say that BGP allows an administrator to set policies on how prefixes are handled by ISPs, this is generally not possible, strictly speaking.

For instance, BGP natively has no concept to allow one AS to tell another AS to restrict advertisement of a prefix to only North American peering customers.

Instead, an ISP generally publishes a list of well-known or proprietary communities with a description for each one, which essentially becomes an agreement of how prefixes are to be treated.

The end user has no technical ability to enforce correct actions being taken by the ISP, though problems in this area are generally rare and accidental.

[17][18] It is a common tactic for end customers to use BGP communities (usually ASN:70,80,90,100) to control the local preference the ISP assigns to advertised routes instead of using MED (the effect is similar).

A bit in the type field within the attribute decides whether the encoded extended community is of a transitive or non-transitive nature.

Another application of MEDs is to advertise the value, typically based on delay, of multiple ASs that have a presence at an IXP, that they impose to send traffic to some destination.

In large networks, this number of sessions may degrade the performance of routers, due to either a lack of memory, or high CPU process requirements.

An RR topology can cut these 90 statements down to 18, offering a viable solution for the larger networks administered by ISPs.

The routing tables managed by a BGP implementation are adjusted continually to reflect actual changes in the network, such as links or routers going down and coming back up.

At the first instance when a route becomes unavailable and quickly reappears, damping does not take effect, so as to maintain the normal fail-over times of BGP.

After the abnormalities have ceased and a suitable length of time has passed for the offending route, prefixes can be reinstated with a clean slate.

In addition, and perhaps even more importantly, larger routing tables take longer to stabilize after a major connectivity change, leaving network service unreliable, or even unavailable, in the interim.

[40] A number of Cisco routers commonly in use had TCAM, a form of high-speed content-addressable memory, for storing BGP advertised routes.

[44] Even if Verizon had not caused the routing table to exceed 512k entries in the short spike, it would have soon happened through natural growth.

If AS2 now wants to send data to prefix 172.16.192.0/18, it will be dropped or a destination unreachable ICMP message will be sent back at the routers of AS2 (not AS1 as before), because 172.16.192.0/18 is not in the routing table.

One method to address the routing table issue associated with load balancing is to deploy Locator/Identifier Separation Protocol (BGP/LISP) gateways within an Internet exchange point to allow ingress traffic engineering across multiple links.

Due to the extent to which BGP is embedded in the core systems of the Internet, and the number of different networks operated by many different organizations which collectively make up the Internet, correcting this vulnerability (such as by introducing the use of cryptographic keys to verify the identity of BGP routers) is a technically and economically challenging problem.

This can then be extended further with features like Cisco's dmzlink-bw which enables a ratio of traffic sharing based on bandwidth values configured on individual links.

Other commercial routers may need a specific software executable image that supports BGP, or a license that enables it.