Talk:Border Gateway Protocol

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. — Preceding unsigned comment added by Gnebulon (talk • contribs) 16:10, 7 February 2011 (UTC)

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.

--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. --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?

--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. - Snaily (talk) 05:19, 1 February 2012 (UTC)

Cisco-specific lines

I Removed these lines from the beginning of the article:

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 IGPs, and IGPs to IBGP.

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.

--Phinze (talk) 09:05, 28 December 2012 (UTC)

Exploits

http://it.slashdot.org/story/13/11/23/2230223/route-injection-attacks-detouring-internet-traffic — Preceding unsigned comment added by 76.177.116.225 (talk) 18:50, 24 November 2013 (UTC)

BGP confederation merge proposal

I proposed merging BGP confederation into this article. Disavian 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. ~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. ~KvnG 15:41, 16 August 2014 (UTC)

MP-BGP redirection

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

 Done ~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! — Preceding unsigned comment added by 97.89.98.145 (talk) 00:06, 6 August 2014 (UTC)

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. Oiyarbepsy (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 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.

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.

References

History?

Seeking historical information including:

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

Thanks. -- GreenC 14:42, 1 December 2015 (UTC)

Indeed, I came here looking to confirm that it is "still known as the three-napkin protocol" - 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 this, and this, and this as a refs. 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. --A5n (talk) 20:50, 1 October 2024 (UTC)

References

External links modified

Hello fellow Wikipedians,

I have just modified 2 external links on Border Gateway Protocol. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit 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 {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 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.

with

The protocol is classified as a path vector protocol.

Websurfer2 (talk) 09:02, 16 March 2018 (UTC)

References

Merger Proposal

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

The result of this discussion was merge. Sirfurboy🏄 (talk) 19:00, 5 March 2020 (UTC)

---

kvng (talk · contribs) proposed merger of Route reflector to here in May 2019. Jimmy Olano (talk · contribs) 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. -- Sirfurboy (talk) 11:53, 22 January 2020 (UTC)

Hi everybody! Hello kvng (talk · contribs)! Sorry by my mistake! Other languages for Wikipedia in English are not vinculant but I want show you, with all due respect, 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!--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. -- 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. ~Kvng (talk) 16:23, 22 January 2020 (UTC)

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

1. We create an IBGP heading, and have subheadings at least for these two subjects and the problem of internal scalability. This involves some reorganisation.
2. 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.
3. 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. -- Sirfurboy (talk) 17:25, 22 January 2020 (UTC)

OK so I forgot about this too! But now I have created a proposed merge at 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. -- Sirfurboy🏄 (talk) 15:43, 2 March 2020 (UTC)

Pinging kvng (talk · contribs) and Jimmy Olano (talk · contribs) -- Sirfurboy🏄 (talk) 07:04, 5 March 2020 (UTC)

Your sandbox version looks great to me. ~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. -- Sirfurboy🏄 (talk) 19:00, 5 March 2020 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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.

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.

Symbol (talk) 20:04, 3 May 2021 (UTC)