Jump to content

Talk:Border Gateway Protocol/Archive 3

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3

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)

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)

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)

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[1] 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

  1. ^ https://www.ietf.org/rfc/rfc4271.txt

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:

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)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Border_Gateway_Protocol/Archive_3&oldid=1304017456"