My FAQs 3 - BGP

port ?
TCP 179

Goals of bgp?
->First, it needed to support the meshlike connectivity of ISP networks.
->It also required extensive policy controls to enforce the administrative policies of each ISP.
->It needed the ability to reliably transmit routing information between BGPpeers.
->Finally, the protocol required the ability to scale route advertisements beyond a few thousand routes

Loop prevention?
Provides loop prevention through an attribute called the AS Path, which is a collection of AS numbers through which a particular route has passed. The use of this attribute also leads to a common description of BGP as a path-vector protocol. In a BGP network, each router knows the networks a route has traversed (the path) and the direction to send a packet for the route (the vector).

EBGP?
When two BGP routers are in different AS networks, the session between them is considered an external BGP (EBGP) connection. By default, an EBGP connection is formed between directly connected peers. This requirement is enforced by setting the time-to-live (TTL) of the IP packet to 1, thereby not permitting an intermediate router to forward the BGP packet. Once the EBGP session is established, the two peers can begin to exchange routing knowledge with each other. All active BGP routes learned from other EBGP sessions are advertised. In addition, all active BGP routes learned from internal BGP peers are advertised.

IBGP?
The connection of two BGP routers within the same AS is called an internal BGP(IBGP) connection. Unlike the EBGP variety, there is no requirement forphysical connectivity between IBGP peers. The TTL of the BGP packets is set to64 to allow for connectivity across an AS. Once the IBGP session is established, routes are exchanged between the peers. By default, only active BGP routes learned from EBGP peers are advertised across an IBGP session.

BGP FSM?
Idle Idle is the initial neighbor state, in which it rejects all incoming session requests. After the BGP process starts, a TCP session is initiated to the remote peer. The local router transitions to the Connect state and begins to listen for a connection initiated by the remote router.
Connect In the Connect state, the local router is waiting for the TCP session to be completed. If it is successful, the local router sends an Open message to the peer and transitions to the OpenSent state. Should the TCP connection attempt fail, the local router resets the ConnectRetry timer and transitions to the Active state. If the ConnectRetry timer reaches 0 while the local router is in the Connect state, the timer is reset and another connection attempt is made. The local router remains in the Connect state.
Active In the Active state, the local router is trying to initiate a TCP session with its peer. If the session establishes successfully, an Open message is sent and the local router transitions to the OpenSent state. If the TCP session fails to establish, the local router initiates another session, sets the ConnectRetry timer to 0, and transitions back to the Connect state. Attempts by the remote router to connect from an unexpected IP address for the session causes the local router to refuse the connection. The local router remains in the Active state and resets the ConnectRetry timer.
OpenSent The OpenSent state is reached upon a successful TCP establishment. The local router sends a BGP Open message and waits for an Open message from the remote peer.
When a valid Open message is received, the local router begins to send Keepalive messages to the remote router. The BGP peers negotiate the session parameters and the local router transitions to the OpenConfirm state. Should a TCP disconnect be received while in this state, the local router terminates the BGP session, resets the ConnectRetry timer, and transitions back to the Active state.
OpenConfirm When the local router receives a valid Open message from the remote peer, the OpenConfirm state is reached. The local router sends Keepalive messages to the peer and waits for a Keepalive message in return.
Established The Established state is achieved when a Keepalive message is received while in the OpenConfirm state. This is the final state of a peer relationship and designates a fully operational connection.
Two BGP peers can exchange routing information only when the Established state is reached. All other BGP peering states designate a nonfunctional session

Message types?
The Open Message The Open message is the first packet BGP sends to a peer after the TCP connection has been established. It allows the two peers to negotiate the parameters of the peer session. These parameters include the BGP version, the hold time for the session, authentication data, refresh capabilities, and support for multiple Network Layer Reachability Information (NLRI).
The Update Message Routing information is sent and withdrawn in BGP using the Update message. If needed, each message contains information previously advertised by the local router that is no longer valid. The same message may also contain new information advertised to the remote peer. Each Update contains a single set of BGP attributes and all routes using those attributes. This format reduces the total number of packets routers send between BGP peers when exchanging routing knowledge.
The Notification Message When a BGP peer detects an error within the session, it sends a Notification message to the remote router and immediately closes both the BGP and TCP sessions.
The Keepalive Message A BGP Keepalive message contains only the 19-octet message header and no other data. These messages are exchanged at one-third the negotiated hold-time value for the session, if necessary. The advertisement of an Update message within the keepalive period resets the timer to 0. In short, a Keepalive is sent only in the absence of other messages for a particular session. Should the local router not receive a Keepalive or Update message within the hold-time period, a Notification message of Hold Time Expired is generated and the session is torn down.

Routing Information bases?
Each BGP router establishes memory locations in which to store routing knowledge. These are collectively known as a Routing Information Base (RIB). A BGP peer maintains three categories of RIBs: the Adjacency-RIB-In, the Local-RIB, and the Adjacency-RIB-Out.
Adjacency-RIB-In An Adjacency-RIB-In table is created on the local router for each established BGP peer. All routes received from the peer are placed in the appropriate memory table
Local-RIB The best path to each destination is stored in the Local-RIB table. These are the routes that thelocal router uses to forward user data traffic
Adjacency-RIB-Out Each established BGP peer also creates its own Adjacency-RIB-Out table for outbound route advertisements. Only routes currently located in the Local-RIB are eligible to be placed in this outbound database. In other words, a BGP router advertises only routes that it is currently using to forward data traffic.

Route selection process?
1. The Next Hop attribute value for each route must be reachable in the local routing table; otherwise, the local router discards the route.
2. The router selects the route with the highest Local Preference attribute value.
3. The router selects the route with the shortest AS Path length.
4. The router selects the route with the smallest Origin attribute value.
5. The router selects the route with the smallest Multiple Exit Discriminator attribute value. This step is executed, by default, only for routes from the same neighboring AS.
6. The router selects routes learned from an EBGP peer over routes learned from an IBGP peer. If the remaining routes are all EBGP-learned routes, the router skips to step 9.
7. The router selects the route with the smallest IGP metric to the advertised BGP Next Hop.
8. If Route Reflection is used for IBGP peering, the router selects the route with the shortest Cluster-List length.
9. The router selects the route from the peer with the smallest numerical Router ID.
10. The router selects the route from the peer with the smallest numerical Peer Address.

BGP attributes?
Optional Bit (Bit 0) An attribute is either well known (a value of 0) or optional (a value of 1).
Transitive Bit (Bit 1) Optional attributes can be either nontransitive (a value of 0) or transitive (a value of 1). Well-known attributes are always transitive.
Partial Bit (Bit 2) Only optional transitive attributes use this bit. A 0 means each BGP router along the path recognized this attribute. A 1 means that at least one BGP router along the path did not recognize the attribute

Next Hop Next Hop, attribute type code 3, is a well-known mandatory attribute
Local Preference Local Preference, attribute type code 5, is a well-known discretionary attribute.
AS Path AS Path, attribute type code 2, is a well-known mandatory attribute.Origin Origin, attribute type code 1, is a well-known mandatory attribute.
Multiple Exit Discriminator Multiple Exit Discriminator (MED), attribute type code 4, is an optional nontransitive attribute.
Community Community, attribute type code 8, is an optional transitive attribute. It is used to administrativelygroup routes for a common policy action.