HCIE-R&S Notes – BGP and BGP4+
BGP messages include:
1. Open: negotiation of capabilities and parameters.
2. Update: announce routes and inform routes to be withdrawn.
3. Keepalive: periodically check accessibility.
4. Notification: report an error.
5. Route-refresh: request the peer to retransmit routes due to routing policy change.
BGP Finite State Machine (FSM)
Idle-> Connect > Active > OpenSent > OpenConfirm > Established
Initially, BGP is in an Idle state, refusing BGP connections. When BGP starts establishing a connection with a peer, it goes into the Connect state (after receiving the Start event from the system). The start event occurs when the administrator configures the BGP process or restarts it.
In Connect state the Connect Retry timer is started (default value is 32s). In this state, BGP tries to establish a BGP connection with the peer. If it is established, BGP sends an Open message. If the connection is not established, BGP goes to the Active state.
In the Active state, BGP keeps trying to establish a BGP connection with the peer. In this state, BGP waits for the peer to initiate a BGP connection. If the Connect timer expires, BGP reverts to Connect state.
In OpenSent State the device sends an Open message and expects an Open message in return. If the device receives a valid Open message, it sends a Keepalive and goes into the OpenConfirm state. If the received Open message is not valid, a Notification is sent and the device goes to Idle state.
In the OpenConfirm state, the device expects to receive a Keepalive message from the peer. Receiving it, it transitions to Established and is able to exchange Update. If a Notification message is received, it goes to the Idle state.
In the Established state, the device exchanges Update, Keepalive, and Route-refresh.
Figure 1 – BGP FSM
BGP attributes
Well-known mandatory: Attributes that must be identified by BGP peers and included in every update message. Without these attributes, errors will occur. AS-PATH, Origin, and Next-hop are well-known mandatory attributes.
Well-known discretionary: Attributes that must be identified by BGP peers, but do not need to be in every update message. Without these attributes, errors do not occur. Local-Pref is a well-known discretionary attribute.
Optional transitive: The BGP peer may not identify these attributes, but still receive and advertise them to the other peers. Community is example.
Optional non-transitive: May not be identified. These attributes are ignored and not sent to other peers. MED, Originator-ID and Cluster-List are examples.
Origin attribute
Indicates how the route was obtained by BGP. Its possible values are IGP, EGP and incomplete. The symbol i indicates IGP, e indicates EGP, and ? indicates incomplete. IGP routes have the highest priority, then EGP and finally incomplete. IGP routes enter the BGP table via the network command, incomplete via the import command. A route will be e just if someone changed the attribute(using a policy, for example).
PrefVal Attribute
Huawei-specific attribute and valid only on the local router. Its default value is 0. In the route selection process, the PrefVal value is first compared. The higher value indicates higher priority.
Next-hop attribute
When advertising a route learned via an EBGP peer to the IBGP peer, the Next-hop value is not changed.
When advertising a locally originated route to an IBGP peer, the Next_Hop value will be the address used to establish BGP peering.
When advertising the route to the EBGP peer, the next-hop is also defined as the IP of the interface used to establish the BGP peering.
BGP Route Selection Criteria
1. If the next-hop of the route is unreachable, the route is discarded.
2. Choose the route with the highest Pref-Val value.
3. Prefer the route with the highest Local-Pref value.
4. Prefer routes: manually summarized, automatically summarized, routes imported using the network command, routes imported using the import command, and routes learned from peers.
5. Prefer routes with the shortest AS-Path.
6. Prefer routes with the highest priority of Origin: IGP-EGP-Incomplete.
7. Prefer routes with the lowest MED.
8. Prefer EBGP routes over IBGP.
9. Prefer routes with the lowest IGP metric to the next-hop of BGP.
10. Prefer routes with the shortest Cluster-List.
11. Prefer routes advertised by router with lowest Router-ID.
12. Prefer routes learned from peer with the lowest IP.
Load Balancing: it is possible to balance routes with equal costs, which is considered equal cost when the rules up to number 8 are equal. Only routes with the same AS-PATH size and the same sequence can be balanced.
BGP4+
Extension to BGP4. It supports multiple address families, including IPv6, VPNv4, and VPNv6. It transmits routes over different families through extended attributes.
When IPv6 routes are transmitted between peers, they inform the IPv6 capability through the Open message. The Capabilities Advertisement field in the Open message is used to communicate extended capabilities.
The MP_REACH_NLRI attribute is used to advertise IPv6 routes. MP_UNREAC
