View source for Talk:Border Gateway Protocol

{{talkheader|noarchive=yes|search=no}}
{{WikiProject banner shell|class=C|
{{WikiProject Computing|importance=|network=yes}}
{{WikiProject Internet|importance=}}
}}
{{Merged-from|512k day|January 2, 2015}}
{{Merged-from|Route reflector|5 March 2020}}
{{Merged-from|BGP confederation|5 March 2020}}
{{archives|search=yes}}

== It uses 20 bytes per header ==

I removed the text
    It uses 20 bytes per header.

because it was in a strange place and it wasn't at all clear what it was talking about.  Someone with the knowledge should explain this and put it where it belongs.  <small><span class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:Gnebulon|Gnebulon]] ([[User talk:Gnebulon|talk]] • [[Special:Contributions/Gnebulon|contribs]]) 16:10, 7 February 2011 (UTC)</span></small><!-- Template:Unsigned --> <!--Autosigned by SineBot-->

== Explantion of how internet routing works ==

So there's currently no place on Wikipedia where you can find an explanation of how routing occurs on the modern Internet. I'm not sure it belongs here, but is it more appropriate on [[Routing]] or [[Router (computing)]]? Please weigh in.

The explanation I'm referring to is the way a router has a list of IP address blocks (like 10.10.1.32/27) which are accessible via each interface, and sends the packet out the interface matching its destination IP. Also, please correct me if I got that wrong.

--[[User:Qwerty0|Qwerty0]] ([[User talk:Qwerty0|talk]]) 00:54, 21 December 2011 (UTC)

:I found some discussion in [[Routing table]] and [[Packet forwarding]]. Some additional cross linking and summarization would be helpful. --[[User:Kvng|Kvng]] ([[User talk:Kvng|talk]]) 15:36, 22 December 2011 (UTC)

::Hmm, I hadn't seen [[Packet forwarding]] before. It's interesting, but still doesn't have the specificity I'm looking for.
::Think of the example where someone comes to Wikipedia wondering how a random router knows what direction to send a packet addressed to 74.125.113.105. It can't have a listing for every IP address in the internet, so how does it decide what direction to send it?
::That's the question I'd like to answer in this article (or maybe in [[Routing]]), using the explanation I referred to in my first post. Any objections? Corrections? Suggestions?
::--[[User:Qwerty0|Qwerty0]] ([[User talk:Qwerty0|talk]]) 09:37, 24 December 2011 (UTC)
:::Perhaps you are referring to ''[[Route-aggregation]]''? Where traffic is sent using ''summary routes''. If so, take a look at [[Supernetwork]]. And (as you asked for it): I believe routing table entries are (have always been) networks, not individual IP numbers. - [[User:Snaily|Snaily]] ([[User talk:Snaily|talk]]) 05:19, 1 February 2012 (UTC)

== Cisco-specific lines ==

I Removed these lines from the beginning of the article:

<blockquote>In the Cisco operating system, IBGP routes have an [[administrative distance]] of 200 and that of EBGP is 20;  IBGP is thus less preferred than either external BGP or any interior routing protocol. Other router implementations also prefer EBGP to [[Interior Gateway Protocol|IGP]]s, and IGPs to IBGP.</blockquote>

I felt like they were much too specific for the introductory paragraph, and didn't fit with the general description of iBGP/eBGP that surrounded them. I tried to find another place for them to go (maybe "Per-neighbor decisions"?) but couldn't decide on where/whether they should go back in. Feedback welcome.

--[[User:Phinze|Phinze]] ([[User talk:Phinze|talk]]) 09:05, 28 December 2012 (UTC)

== Exploits ==

http://it.slashdot.org/story/13/11/23/2230223/route-injection-attacks-detouring-internet-traffic  <span style="font-size: smaller;" class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/76.177.116.225|76.177.116.225]] ([[User talk:76.177.116.225|talk]]) 18:50, 24 November 2013 (UTC)</span><!-- Template:Unsigned IP --> <!--Autosigned by SineBot-->

== [[BGP confederation]] merge proposal ==

I proposed merging [[BGP confederation]] into this article. {{u|Disavian}} [https://en.wikipedia.org/w/index.php?title=BGP_confederation&oldid=597398444&diff=prev removed the merge banner] from [[BGP confederation]] with the edit comment reproduced below. I have restored the merge banner in hopes of having a wider discussion about this proposal. ~[[user talk:Kvng|KvnG]] 19:00, 27 February 2014 (UTC)

:The BGP article does not clearly define this term, which is linked from other articles - rv merge tag

For symmetry, this merge would also need to involve [[Route reflector]]. Instead of merging, I've decided to improve [[BGP confederation]]. Once this article is improved a bit, it may be easier to see how or whether to do these merges. ~[[user talk:Kvng|KvnG]] 15:41, 16 August 2014 (UTC)

== MP-BGP redirection ==

'''MP-BGP''' redirects here (to [[BGP]]). Should redirect to [[Multiprotocol_BGP]].
[[User:Kjrrp|Kjrrp]] ([[User talk:Kjrrp|talk]]) 15:05, 9 June 2014 (UTC)

{{Done}} ~[[user talk:Kvng|KvnG]] 13:20, 7 June 2014 (UTC)

By clicking the "Save page" button, you agree to the Terms of Use and you irrevocably agree to release your contribution under the CC BY-SA 3.0 License and the GFDL with the understanding that a hyperlink or URL is sufficient for CC BY-SA 3.0 attribution.

Feel free to call at 704 in this wiki for more questions, Thank You!  <span style="font-size: smaller;" class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/97.89.98.145|97.89.98.145]] ([[User talk:97.89.98.145|talk]]) 00:06, 6 August 2014 (UTC)</span><!-- Template:Unsigned IP --> <!--Autosigned by SineBot-->

== Merged in 512k day ==

Based on discussion at [[Wikipedia:Articles for deletion/512k day]], I merged [[512k day]] here, into the Routing table growth section. It might be too much content for the section, so feel free to trim as you see fit. [[User:Oiyarbepsy|Oiyarbepsy]] ([[User talk:Oiyarbepsy/justasig|talk]]) 15:43, 2 January 2015 (UTC)

== State machine transitions ==

The text is incorrect in some places, and contradictory in others. Example:

*'''Idle State''':
** Refuse all incoming BGP connections
...
** Listens for a TCP connection from its peer.

The RFC<ref>https://www.ietf.org/rfc/rfc4271.txt</ref> is a bit chunky, so it looks like whoever wrote this has combined the initial Idle State data with what to do after receiving a Manual/Automatic Start message.

I appreciate the irony of submitting criticism without proposing an alternative :) I do however think it's important to have a section about this here in the talk page, as this part could ultimately be better written.

[[User:Samrussellnz|Samrussellnz]] ([[User talk:Samrussellnz|talk]]) 23:09, 7 November 2015 (UTC)

=== Potential new version ===
In order to make decisions in its operations with peers, a BGP peer uses a simple [[finite state machine]] (FSM) that consists of six states: Idle; Connect; Active; OpenSent; OpenConfirm; and Established. For each peer-to-peer session, a BGP implementation maintains a state variable that tracks which of these six states the session is in. The BGP defines the messages that each peer should exchange in order to change the session from one state to another. 

==== Idle state ====

* No resources are allocated to the peer
* All incoming BGP connections are refused

The [[finite state machine]] (FSM) will transition to a new state if it receives one of the following messages:

*'''AutomaticStart/ManualStart''':
** Initializes all BGP resources for the peer connection
** sets the ConnectRetryCounter to zero
** starts the ConnectRetryTimer with the initial value
** initiates a TCP connection to the other BGP peer
** listens for a connection that may be initiated by the remote BGP peer
** transitions to the Connect state


*'''AutomaticStart/ManualStart (with PassiveTcpEstablishment)''':
** Initializes all BGP resources
** sets the ConnectRetryCounter to zero
** starts the ConnectRetryTimer with the initial value
** listens for a connection that may be initiated by the remote BGP peer
** transitions to the Active state

BGP initializes all resources, refuses all inbound BGP connection attempts and initiates a TCP connection to the peer. The second state is "Connect". In the "Connect" state, the router waits for the TCP connection to complete and transitions to the "OpenSent" state if successful. If unsuccessful, it starts the ConnectRetry timer and transitions to the "Active" state upon expiration. In the "Active" state, the router resets the ConnectRetry timer to zero and returns to the "Connect" state. In the "OpenSent" state, the router sends an Open message and waits for one in return in order to transition to the "OpenConfirm" state. Keepalive messages are exchanged and, upon successful receipt, the router is placed into the "Established" state. In the "Established" state, the router can send/receive: Keepalive; Update; and Notification messages to/from its peer.

*'''Idle State''':
** Refuse all incoming BGP connections
** Start the initialization of event triggers.
** Initiates a TCP connection with its configured BGP peer.
** Listens for a TCP connection from its peer.
** Changes its state to Connect.
** If an error occurs at any state of the FSM process, the BGP session is terminated immediately and returned to the Idle state. Some of the reasons why a router does not progress from the Idle state are:
*** TCP port 179 is not open.
*** A random TCP port over 1023 is not open.
*** Peer address configured incorrectly on either router.
*** AS number configured incorrectly on either router.
*'''Connect State''':
**Waits for successful TCP negotiation with peer.
**BGP does not spend much time in this state if the TCP session has been successfully established.
**Sends Open message to peer and changes state to OpenSent.
**If an error occurs, BGP moves to the Active state. Some reasons for the error are:
*** TCP port 179 is not open.
*** A random TCP port over 1023 is not open.
*** Peer address configured incorrectly on either router.
*** AS number configured incorrectly on either router.
* '''Active State''':
** If the router was unable to establish a successful TCP session, then it ends up in the Active state.
** BGP FSM tries to restart another TCP session with the peer and, if successful, then it sends an Open message to the peer.
** If it is unsuccessful again, the FSM is reset to the Idle state.
** Repeated failures may result in a router cycling between the Idle and Active states. Some of the reasons for this include:
*** TCP port 179 is not open.
*** A random TCP port over 1023 is not open.
*** BGP configuration error.
*** Network congestion.
*** Flapping network interface.
* '''OpenSent State''':
** BGP FSM listens for an Open message from its peer.
** Once the message has been received, the router checks the validity of the Open message.
** If there is an error it is because one of the fields in the Open message does not match between the peers, e.g., BGP version mismatch, the peering router expects a different My AS, etc. The router then sends a Notification message to the peer indicating why the error occurred.
** If there is no error, a Keepalive message is sent, various timers are set and the state is changed to OpenConfirm.
* '''OpenConfirm State''':
** The peer is listening for a Keepalive message from its peer.
** If a Keepalive message is received and no timer has expired before reception of the Keepalive, BGP transitions to the Established state.
** If a timer expires before a Keepalive message is received, or if an error condition occurs, the router transitions back to the Idle state.
* '''Established State''':
** In this state, the peers send Update messages to exchange information about each route being advertised to the BGP peer.
** If there is any error in the Update message then a Notification message is sent to the peer, and BGP transitions back to the Idle state.
** If a timer expires before a Keepalive message is received, or if an error condition occurs, the router transitions back to the Idle state.

{{reflist-talk}}

== History? ==

Seeking historical information including:

* When was it first written
* Who first used it
* What did it replace/superseded.

Thanks. -- [[User:Green Cardamom|<span style="color:#006A4E;">'''Green'''</span>]][[User_talk:Green Cardamom|<span style="color:#009933;">'''C'''</span>]] 14:42, 1 December 2015 (UTC)
:Indeed, I came here looking to confirm that it is "still known as the three-napkin protocol"<ref>[http://www.washingtonpost.com/sf/business/2015/05/31/net-of-insecurity-part-2/ Washington Post: "Net of Insecurity"]</ref> - can I suggest the following text:
::''The genesis of BGP was in 1989 when [[Kirk Lougheed]] of Cisco and [[Yakov Rekhter]] were sharing a meal at an IETF conference. They famously sketched the outline of their new routing protocol on the back of some napkins, hence references to the “Two Napkin Protocol”.'' 
: - with [http://www.computerhistory.org/atchm/the-two-napkin-protocol/ this], [http://weare.cisco.com/c/r/weare/amazing-stories/amazing-things/two-napkin.html and this], [http://www.cisco.com/c/en/us/about/open-source/open-standards/border-gateway-protocol-bgp.html and this] as a refs. [[User:Snori|Snori]] ([[User talk:Snori|talk]]) 04:25, 23 May 2017 (UTC)
:: {{Done}} I also added the CHM/Cisco referenced issue of The Packet as a reference. Since both CHM/Cisco references have the same author. I was unable to find the full issue of "The Packet", only the cover. --[[User:A5n|A5n]] ([[User talk:A5n|talk]]) 20:50, 1 October 2024 (UTC)

{{reflist-talk}}

== External links modified ==

Hello fellow Wikipedians,

I have just modified {{plural:2|one external link|2 external links}} on [[Border Gateway Protocol]]. Please take a moment to review [https://en.wikipedia.org/w/index.php?diff=prev&oldid=748061596 my edit]. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit [[User:Cyberpower678/FaQs#InternetArchiveBot|this simple FaQ]] for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20130928115120/http://www.orbit-computer-solutions.com:80/BGP.php to http://www.orbit-computer-solutions.com/BGP.php
*Added archive https://web.archive.org/web/20121016133207/http://bgptables.merit.edu/ to http://bgptables.merit.edu/

When you have finished reviewing my changes, please set the ''checked'' parameter below to '''true''' or '''failed''' to let others know (documentation at {{tlx|Sourcecheck}}).

{{sourcecheck|checked=false}}

Cheers.—[[User:InternetArchiveBot|'''<span style="color:darkgrey;font-family:monospace">InternetArchiveBot</span>''']] <span style="color:green;font-family:Rockwell">([[User talk:InternetArchiveBot|Report bug]])</span> 03:07, 6 November 2016 (UTC)

== path vector vs. distance vector citation needed ==
I removed the distance-vector reference because a path vector is not the same thing.  A citation is needed for referring to BGP as a distance-vector routing protocol, otherwise the text as presented is confusing to people who don't know the difference, and nonsensical to people who do.

Replace:

:The protocol is classified as a [[path vector protocol]] but is sometimes also classed as a [[distance-vector routing protocol]]{{Citation needed|date=July 2017}}.

with

:The protocol is classified as a [[path vector protocol]].<ref>{{cite web|title=Network Routing with Path Vector Protocols: Theory and Applications|url=https://conferences.sigcomm.org/sigcomm/2003/papers/p49-sobrinho.pdf|access-date=March 16, 2018|date=2003|last=Sobrinho|first=João Luís}}</ref>
[[User:Websurfer2|Websurfer2]] ([[User talk:Websurfer2|talk]]) 09:02, 16 March 2018 (UTC)

{{reflist-talk}}

== Merger Proposal ==
{{Discussion top|result=The result of this discussion was '''merge'''. [[User:Sirfurboy|Sirfurboy🏄]] ([[User talk:Sirfurboy|talk]]) 19:00, 5 March 2020 (UTC)}}
{{User|kvng}} proposed merger of [[Route reflector]] to here in May 2019. {{User|Jimmy Olano}} proposed merger of [[BGP confederation]] to here in  August 2019 (but his edit summary seems to suggest he wanted to merge with [[Route reflector]]). Both proposals seem to have foundered for lack of any discussion. Although [[WP:SILENCE]] could be assumed to allow the merge to proceed, I notice that kvng indicated in talk that they were concentrating on improving [[Route reflector]] and may thus no longer support his/her own proposal.

I also considered removing the merge templates, but the stub nature of [[BGP confederation]] and its obvious relevance to this page makes me think the proposal was a good idea, and a merger of [[Route reflector]] may perhaps still be a good idea, despite the expanded article. Thus I am refreshing the merger discussion here and propose to leave it open one more week to see if we can gain consensus whether to merge the articles or not. Please state your preference for each article. Thanks. -- [[User:Sirfurboy|Sirfurboy]] ([[User talk:Sirfurboy|talk]]) 11:53, 22 January 2020 (UTC)

: Hi everybody! Hello {{User|kvng}}! Sorry by my mistake! Other languages for Wikipedia in English are not vinculant but I want show you, with all due respect, [[:de:Border Gateway Protocol|same article in Germany language]]:

 1 Protokollbeschreibung
 2 Anwendungsbereich
    2.1 EBGP
    2.2 IBGP
        2.2.1 Vollständige Vermaschung
        2.2.2 Route Reflector
        2.2.3 Confederation
        2.2.4 Loopbackadresse
: See 2.2.2 and 2.2.3, I believe that with this is clear my position, all my efforts for create a good article. Have a nice day all of you!--[[User:Jimmy Olano|Jimmy Olano]] ([[User talk:Jimmy Olano|talk]]) 12:16, 22 January 2020 (UTC) P.S. any improve now on any three articles will be welcome; after merge we will help again for redundances, style, etc.
:: Thanks Jimmy, yes I think the structure on the German page makes sense. -- [[User:Sirfurboy|Sirfurboy]] ([[User talk:Sirfurboy|talk]]) 14:12, 22 January 2020 (UTC)

: My talk comment from 2014 at [[Talk:Border_Gateway_Protocol#BGP_confederation_merge_proposal]] indicates that I would improve [[BGP confederation]] and then reassess. It looks like improvement happened, reassessment didn't. I do think a merge should be considered here and I assume the silence is because no one, myself included, has gotten around to evaluating it. We need someone to outline how it will work. The German model can't be directly applied here because we comingled EBGP and IBGP in our coverage here. ~[[User:Kvng|Kvng]] ([[User talk:Kvng|talk]]) 16:23, 22 January 2020 (UTC)

:: Thanks kvng. Yes, where to put the merged material needs some thought. Some possibilities: 

::# We create an IBGP heading, and have subheadings at least for these two subjects and the problem of '''internal scalability'''. This involves some reorganisation.
::# We create these as sub headings of '''Problems and mitigation''' -> '''internal scalability'''. This makes minimal changes but would perhaps be an ugly solution as it would require fourth level headings.
::# We move '''Internal scalability''' out of '''Problems and Mitigations''' and perhaps rename that heading to something else. That is a halfway house that requires a small amount of restructuring, but still makes these a sub heading of "internal scalability" rather than IBGP. -- [[User:Sirfurboy|Sirfurboy]] ([[User talk:Sirfurboy|talk]]) 17:25, 22 January 2020 (UTC)
::::OK so I forgot about this too! But now I have created a proposed merge at [https://en.wikipedia.org/wiki/User:Sirfurboy/sandbox#Internal_scalability my sandbox]. I have adjusted heading levels a little so that Internal scalability is an L2 heading (heading 3) and then the merged content from [[Route reflector]] and [[BGP confederation]] are l2 headiinsg (3.1 and 3.2). If you are content with the change I will close and  complete the merge. If you don't approve, perhaps we can find another way to carry out the merge. -- [[User:Sirfurboy|Sirfurboy🏄]] ([[User talk:Sirfurboy|talk]]) 15:43, 2 March 2020 (UTC)
::::Pinging {{User|kvng}} and {{User|Jimmy Olano}} -- [[User:Sirfurboy|Sirfurboy🏄]] ([[User talk:Sirfurboy|talk]]) 07:04, 5 March 2020 (UTC)
:::::Your sandbox version looks great to me. ~[[User:Kvng|Kvng]] ([[User talk:Kvng|talk]]) 14:28, 5 March 2020 (UTC)
::::::Thanks. I also had a 'thank from Jimmy Olano so I will start work on the merge. -- [[User:Sirfurboy|Sirfurboy🏄]] ([[User talk:Sirfurboy|talk]]) 19:00, 5 March 2020 (UTC)
{{Discussion bottom}}

== Correctness question - someone please take a look at this ==

"The main difference between iBGP and eBGP peering is in the way routes that were received from one peer are propagated to other peers. For instance, new routes learned from an eBGP peer are typically redistributed to all iBGP peers as well as all other eBGP peers (if transit mode is enabled on the router). However, if new routes are learned on an iBGP peering, then they are re-advertised only to all '''eBGP''' peers."

Shouldn't the bolded be iBGP, not eBGP? I'm not an expert but hoping an expert can chime in.

[[User:Qwertyca|Qwertyca]] ([[User talk:Qwertyca|talk]]) 22:42, 1 May 2021 (UTC)


:Absolutely not, the article is correct.
:* eBGP → iBGP + other eBGP
:* iBGP → eBGP
:
:Propagating from iBGP to other iBGP is the job of a Route Reflector.
[[User:Symbol|Symbol]] ([[User talk:Symbol|talk]]) 20:04, 3 May 2021 (UTC)