- 1 Overview
- 2 Configuration
- 3 Route Reflectors
- 4 BGP Failure Detection Mechanisms
- 5 Path Selection
- 6 Soft Reconfiguration vs Route Refresh
- 7 Helpful Articles
BGP is a path vector routing protocol.
- RFC 4271
- TCP Port 179
The message types are defined in section 4 of rfc4271.
- OPEN (1)
- After a TCP connection is established, the first message sent by each side is an open message. If the OPEN message is acceptable, a KEEPALIVE message confirming the OPEN is sent back.
- KEEPALIVE (4)
- The main purpose of this type of message is for the heartbeat between BGP peers. By default, the KEEPALIVEs are sent once every 60 seconds with a hold time 180 seconds. If you set the KEEPALIVE interval to 0, it will disable the keepalives. One thing to note is that KEEPALIVE messages are also sent as an ACK to initial OPEN messages.
- UPDATE (2)
- Contains the network layer reachability information (NLRI) and path attributes. Used to remove or "withdraw" routes.
- ROUTE-REFRESH (5)
- Defined in rfc2918. Prior to ROUTE-REFRESH, soft reconfiguration was used. ROUTE-REFRESH allows for a dynamic exchage of route refresh requests between BGP speakers and subsequent re-advertisements of the respective Adj-RIB-Out.
- NOTIFICATION (3)
- Seen when there has been a BGP session reset, BGP capabilities have changed or a hold time expiration.
Finite State Machine (FSM)
This section discusses the difference states that a BGP speaker will go through to become an active peer. This is described in detail in section 8 of rfc4271.
- A BGP speaker will stay in this state if it is not trying to set up a BGP session. This can be caused by receiving a NOTIFICATION message indicating a mismatch between the peers or the speaker may be waiting for an interface to come up.
- Router is waiting for the successful completion of its TCP 3-way handshake. If this is successful, the router transitions to the OpenSent state. However, if the connection attempt fails, the local router resets the ConnectRetry time and transitions to the Active state. The peer with the higher router ID becomes the router that manages the BGP session and the connection attempted by the other router is abandoned.
- In this state, BGP is trying to estable a TCP connection with the peer (generally seen if BGP was unable to establish the TCP connection in the Connect state). If successful, BGP transitions to the OpenSent state. If the TCP session fails to establish, the local router initates another session, sets the ConnectRetry time to 0 and transistions backs to the Connect state. During this state, if the remote peer attempts to establish a connection to the local router using the wrong IP address, the local router will refuse the connection. The local router will remain in the active state and reset the ConnectRetry timer. The router also may be stuck in Active if TCP 179 is not open for the peer.
- The router is in this state when it sends the OPEN message and has not yet received the OPEN message back from its peer. In this state, KEEPALIVEs reset timers and the hold time is also negotiated (smaller value always selected). If it receives a NOTIFICATION, the state will be reset back to idle.
- BGP speaker has received an OPEN message from the peer but has not received a KEEPALIVE.
- BGP speakers are exchanging KEEPALIVE messages. This is when UPDATE messages can be sent.
By default, when trying to establish an eBGP neighborship, the neighbor must be directly connected as the packets have a TTL of 1. The BGP router wont even try to establish a neighborship with the peer because the router knows that the neighbor is not directly connected; this can be seen with the "show ip bgp neighbors" command. To disable this check, use the "disable-connected-check" for the eBGP peer. When you disable the connected check, the peer may still not come up since the TTL is still set as 1. You can increase the TTL with the "ebgp-multihop <HOPS>" command for the eBGP peer.
Multihop vs TTL Security
Below is a basic configuration to establish an eBGP and iBGP neighborship.
router bgp 65500 ! !iBGP neighborship (same AS number) neighbor 10.1.1.1 remote-as 65500 ! !eBGP neighborship (different as number) neighbor 10.200.1.2 remote-as 65300
- bgp router-id 18.104.22.168
- Statically sets the router-id. This will reset your BGP neighborships.
- This is typically always used on neighbors that peer with an eBGP and iBGP neighbor (borders). This is because the iBGP neighbor may not have the next hop address in it's routing table unless you redistribute it via BGP or an IGP. This will change the next hop attribute for received updates to the devices own IP address. When you use next-hop-self on RRs, the clause only affects the next hop of eBGP learned routes because the next hop of reflected routes should not be changed.
Route reflectors will send updates to other iBGP peers depending on the following:
- Routes from a nonclient peer - Reflects to all the clients within the cluster.
- Routes from a client peer - Reflects to all the nonclient peers and also to the client peers.
- Routes from an eBGP peer - Sends the update to all client and nonclient peers.
Route reflectors use a couple of different mechanisms to prevent routing loops.
- This is an optional, nontransitive BGP attribute that is 4 bytes long. An RR creates this attribute. The attribute carries the router ID (RID) of the originator of the route in the local AS. If, due to poor configuration, the routing information comes back to the originator, the information is ignored.
- A cluster list is a sequence of cluster IDs that the route has passed. When an RR reflects a route from the RR clients to nonclients outside of the cluster, the RR appends the local cluster ID to the cluster list. If this update has an empty cluster list, the RR creates one. With this attribute, an RR can identify if the routing information has looped back to the same cluster due to poor configuration. If the local cluster ID is found in the cluster list, the advertisement is ignored. More info.
BGP Failure Detection Mechanisms
Fast BGP Peering Session Deactivation
This feature is on by default for eBGP sessions and tracks the outgoing interface associated with the BGP session. As soon as the interface reports as down, the BGP session is deactivated. You can dampen interface flapping using IP Event Dampening. To disable fast peering session deactivation, use the no bgp fast-external-fallover command.
Some providers may change the origin code for routes received by eBGP neighbors to a single origin code so the path selection doesn't prefer an "origin IGP" route over an "origin incomplete" route. This allows the other path selectors (MED, External, IGP Cost, etc) to take over to try and automatically select the best path. The origin code isn't always the best way to determine which path is best.
- i - Origin IGP: Seen when the network command or aggregate-address was used to advertise the network.
- e - EGP: This is rarely used as EGP was deprecated as of IOS 12.2. EGP was the predeccesor to BGP (RFC904
- ? - Origin incomplete: Route is marked as origin incomplete when using a redistribute command to advertise the network. This is because it is unknown where the route originated from when it was redistributed.
Soft Reconfiguration vs Route Refresh
- clear ip bgp * soft in
- Requests peer send their Adj-RIB-Out for that peering session.
- Does NOT require the peer to be configured with "neighbor x.x.x.x soft-reconfig inbound".
- The original non-disruptive method to refresh the BGP Adj-RIBs-In/Out.
- Copy of all received routes are maintained on a per neighbor basis
- Can use a lot of memory if you're receiving the full BGP routing table from multiple peers.
Cisco - Case Studies