No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

Configuration Guide - IP Unicast Routing

CloudEngine 8800, 7800, 6800, and 5800 V200R005C10

This document describes the configurations of IP Unicast Routing, including IP Routing, Static Route, RIP, RIPng, OSPF, OSPFv3, IPv4 IS-IS, IPv6 IS-IS, BGP, Routing Policy, and PBR.
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
BGP Fundamentals

BGP Fundamentals

BGP peer establishment, update, and deletion involve five types of messages, six state machine states, and five route exchange rules.

BGP Messages

BGP peers exchange the following messages, among which Keepalive messages are periodically sent and other messages are triggered by events.

  • Open message: is used to establish BGP peer relationships.

  • Update message: is used to exchange routes between BGP peers.

  • Notification message: is used to terminate BGP connections.

  • Keepalive message: is used to maintain BGP connections.

  • Route-refresh message: is used to request the peer to resend routes if routing policies are changed. Only the BGP devices supporting route-refresh can send and respond to Route-refresh messages.

BGP State Machine

As shown in Figure 9-2, a BGP device uses a finite state machine (FSM) to determine its operations with peers. The FSM has six states: Idle, Connect, Active, OpenSent, OpenConfirm, and Established. Three common states are involved in BGP peer establishment: Idle, Active, and Established.

Figure 9-2 BGP state machine

  1. The Idle state is the initial BGP state. In Idle state, the BGP device refuses all connection requests from neighbors. The BGP device initiates a TCP connection with its BGP peer and changes its state to Connect only after receiving a Start event from the system.
    NOTE:
    • The Start event occurs when an operator configures a BGP process or resets an existing BGP process or when the router software resets a BGP process.

    • If an error occurs at any state of the FSM, for example, the BGP device receives a Notification message or TCP connection termination notification, the BGP device returns to the Idle state.

  2. In Connect state, the BGP device starts the Connect Retry timer and waits to establish a TCP connection.

    • If the TCP connection is established, the BGP device sends an Open message to the peer and changes to the OpenSent state.
    • If the TCP connection fails to be established, the BGP device moves to the Active state.
    • If the BGP device does not receive a response from the peer before the Connect Retry timer expires, the BGP device attempts to establish a TCP connection with another peer and stays in Connect state.
  3. In Active state, the BGP device keeps trying to establish a TCP connection with the peer.

    • If the TCP connection is established, the BGP device sends an Open message to the peer, closes the Connect Retry timer, and changes to the OpenSent state.
    • If the TCP connection fails to be established, the BGP device stays in Active state.
    • If the BGP device does not receive a response from the peer before the Connect Retry timer expires, the BGP device returns to the Connect state.
  4. In OpenSent state, the BGP device waits for an Open message from the peer and then checks the validity of the received Open message, including the AS number, version, and authentication password.

    • If the received Open message is valid, the BGP device sends a Keepalive message and changes to the OpenConfirm state.
    • If the received Open message is invalid, the BGP device sends a Notification message to the peer and returns to the Idle state.
  5. In OpenConfirm state, the BGP device waits for a Keepalive or Notification message from the peer. If the BGP device receives a Keepalive message, it transits to the Established state. If it receives a Notification message, it returns to the Idle state.
  6. In Established state, the BGP device exchanges Update, Keepalive, Route-refresh, and Notification messages with the peer.

    • If the BGP device receives a valid Update or Keepalive message, it considers that the peer is working properly and maintains the BGP connection with the peer.
    • If the BGP device receives an invalid Update or Keepalive message, it sends a Notification message to the peer and returns to the Idle state.
    • If the BGP device receives a Route-refresh message, it does not change its status.
    • If the BGP device receives a Notification message, it returns to the Idle state.
    • If the BGP device receives a TCP connection termination notification, it terminates the TCP connection with the peer and returns to the Idle state.

Route Exchange Rules

A BGP device adds optimal routes to the BGP routing table to generate BGP routes. After establishing a BGP peer relationship with a peer, the BGP device follows the following rules to exchange routes with the peer:

  • Advertises the BGP routes received from IBGP peers only to its EBGP peers.

  • Advertises the BGP routes received from EBGP peers to its EBGP peers and IBGP peers.

  • Advertises the optimal route to its peers when there are multiple valid routes to the same destination.

  • Sends only updated BGP routes when BGP routes change.

  • Accepts all the routes sent from its peers.

Translation
Download
Updated: 2019-04-20

Document ID: EDOC1100074760

Views: 56603

Downloads: 62

Average rating:
This Document Applies to these Products
Related Version
Related Documents
Share
Previous Next