• BGP is designed and optimized for routing between ASs, even though it can be used to route within an AS.
• An IGP is required for eBGP
• No IGP is required for iBGP

• Considered a path vector protocol because BGP determines the best loop-free path via various BGP path attributes.
• Keeps track of all the ASs it traverses and rejects any routes that would cause a loop.

1. AS 1 advertises its route 10.1.1.0/24 to AS 2 as AS Path 1.
2. AS 2 learns how to reach AS 1's network of 10.1.1.0/24 via AS Path 1.
3. AS 2 adds its AS path to AS Path 1 and advertises it to AS 4 as AS Path 2 1.
4. AS 4 learns how to reach AS 1's network of 10.1.1.0/24 via AS Path 2 1.
5. AS 4 adds its AS path to AS Path 2 1 and advertises it to AS 3 as AS Path 4 2 1.
6. AS 3 learns how to reach AS 1's network of 10.1.1.0/24 via AS Path 4 2 1.
7. AS 3 adds its AS path to AS Path 4 2 1 and advertises it to AS 1 as AS Path 3 4 2 1.
8. AS 1 rejects the advertisement because its own ASN is in the AS Path.
9. AS 3 also advertises AS path 3 4 2 1 to AS 2 and AS 2 rejects the advertisement because its own ASN is in the AS Path.

• This is how eBGP creates a loop-free topology.
• The BGP attribute for the AS Path variable is called AS_PATH.
• AS_PATH Lab

• ASNs are 2 bytes, providing 65,535 ASNs, 2^16
• ASNs were expanded to 4 bytes, providing 4,294,967,295 ASNs, 2^32
• Private ASNs
  • 64,512 - 65,534
  • 4,200,000,000 - 4,294,967,294
• IANA is global authority to assign ASNs
  • Requirements:
    • Proof of a publicly allocated network range
    • Proof that Internet connectivity is provided through multiple connections
    • Need for a unique route policy from your providers
• Best practice is use private ASNs only in private networks

• Well-known mandatory
  • Must be recognized by all BGP implementations
  • Must be included with every prefix advertisement
• Well-known discretionary
  • Must be recognized by all BGP implementations
  • Optional to be included with every prefix advertisement
• Optional transitive
  • Optional to be recognized by all BGP implementations
  • Can be set to traverse with the route advertisement from AS to AS
• Optional non-transitive
  • Optional to be recognized by all BGP implementations
  • Cannot be shared from AS to AS
• Network Layer Reachability Information (NLRI)
  • Is a routing update that includes:
    • The network prefix
    • Prefix-length
    • Any BGP path attributes specific to that route

• Ensures a loop-free path
• The BGP well-known AS_PATH attribute includes a complete listing of all ASNs that the prefix advertisement has traversed from its source autonomous system
• AS_PATH will discard any routes received with its ASN listed in the received AS_PATH attribute
• Address Families
  • AFI - Address Family Identifier
    • Identifies the protocol
    • Correlates to a specific network protocol such as IPv4, IPv6, VPN, and so on
    • Additional granularity is provided by a subsequent address family identifier (SAFI)
  • SAFI - Subsequent Address Family Identifier
    • Identifies how the protocol behaves
    • Unicast, labeled unicast, and multicast
  • A separate database and configuration for each address family
    • Allows routing policies to differ from one address family to another within the same BGP session

• BGP neighbors are defined by IP address
• TCP port 179
• Neighbors in the same network use the ARP table to locate the IP address of the peer
• Multihop BGP sessions require route table information to determine reachability of the peer's IP address

• Establishes BGP adjacency
• Both sides negotiate session capabilities before a BGP peering establishes
• Contains version number, ASN of the originating router, hold time, BGP identifier, and other optional parameters

• Sets the timer in seconds for each BGP neighbor
• An update or keepalive will reset the timer
• When the timer reaches 0, the BGP session is torn down

• BGP router ID (RID) is a 32-bit unique number that identifies the BGP router in the advertised prefixes as the BGP identifier
• A non-zero value must be set for neighborships to form
  • IOS
    • Highest IP address of the loopback interfaces that are up
    • Highest IP address of the interfaces that are up
  • IOS-XR
    • Lowest IP address of the loopback interfaces that are up
    • Otherwise, a value of 0.0.0.0 will be set and no neighborships will form
  • When the RID is changed, BGP sessions will reset and reestablish

• Keepalive messages are used to see if neighbors are still alive
• Exchanged every one-third of the agreed upon hold time
• Hold timer default of 180 seconds, so the keepalive timer is 60 seconds
• When the hold time reaches 0, no keep alive messages are sent between the BGP neighbors

• Advertises any feasible routes, withdraws previously advertised routes, or can do both
• Includes the NLRI prefixes and associated BGP path attributes when advertising prefixes
• Withdrawn NLRIs include only the prefix
• An Update can also contain a Keepalive to reduce network traffic
• Additional information:
  • BGP tries to use the largest size packet to improve network convergence time. The update may include NLRI's prefixes in the message. BGP relies on the TCP maximum segment size (MSS) to define the maximum size of the data payload, and normally bases the calculation on the outbound interface MTU. Multihop BGP sessions may encounter problems if a smaller MTU link is present in the path. BGP includes a MTU path discovery mechanism to detect this issue but might encounter problems with asymmetric routing or firewalls.
  • The MSS can be be set to a value within tolerance of a transit router with the global configuration command ip tcp mss 500-1460 on IOS nodes, and with the equivalent command tcp mss 68-10000 for IOS-XR routers.

• A notification message is sent when an error is detected with the BGP session such as a hold timer expiring, neighbor capabilities changing, or a BGP session reset is requested.
• This will cause the BGP session to close

• A BGP session is the established adjacency between two BGP routers.
• BGP sessions are always point-to-point (P2P) and are categorized into two types:
  • Internal BGP (iBGP)
    • Are in the same AS or confederation
    • Are assumed to be more secure than eBGP and as a result, security is lowered
    • Default AD = 200 upon installing into the router's RIB
  • External BGP (eBGP)
    • Are in a different AS
    • Default AD = 20 upon installing into the router's RIB

• Idle
• Connect
• Active
• OpenSent
• OpenConfirm
• Established

• First state of BGP FSM
• BGP tries to establish a TCP connection to the peer and listens for a new connect from a peer
• If an error causes BGP to back to the idle state for a second time, the ConnectRetryTimer is set to 60 seconds and must decrement to 0 before the connection can be initiated again.
• Further failures to leave the idel state result in the ConnectRetryTimer doubling in length from the previous time.

• BGP initiates the TCP connection
• If the three-way TCP handshake completes, the established BGP session BGP process reset the ConnectRetryTimer and sends the open message to the neighbor and changes to the OpenSent state.
• If the ConnectRetry timer depletes before this stage is complete, a new TCP connection is attempted, the ConnectRetry timer is reset, and the state is moved to active.
• If any other input is received, the state is changed to idle.
• During this stage, the neighbor with the highest IP address manages the connection.
• The router initiating the request uses a dynamic source port, but the destination port is always 179.
• show tcp brief
• show tcp brief | e “LISTEN|CLOSED”
• Note:
  • Most service providers typically assign their customers the higher IP address because this helps with troubleshooting issues caused by ACLs or firewall rules.

• BGP starts a new TCP three-way handshake
• If a connection is established, an open message is sent, the hold timer is set to 4 minutes, and the state moves to OpenSent
• If this attempt for TCP connection fails, the state moves back to the connect state and resets the ConnectRetryTimer

• An open message has been sent from the originating router and is awaiting an open message from the other router
• Once the originating router receives the open message from the other router, both open messages are checked for errors, the following items are compared:
  • BGP versions must match
  • The source IP of the open message must match the IP that is configured for the neighbor
  • ASN in the open message must match what is configured for the neighbor
  • BGP RID must be unique. If a RID doesn't exist, this condition is not met
  • Security parameters (password, TTL, and so on)
• If the open messages have no errors, then the hold time is negotiated (lower value wins), and a keepalive message is sent (assuming the value is not set to 0)
• The connection state is then moved to OpenConfirm
  • If an error is found in the open message, a notification message is sent, and the state is moved back to idle
• If TCP receives a disconnect message, BGP closes the connection, resets the ConnectRetryTimer, and sets the state to active
• Any other input in this process results in the state moving to idle

• BGP waits for a keepalive or notification message
• Upon receipt of a neighbor's keepalive, the sate is moved to established
• If the hold timer expires, a stop event occurs, or a notification message is received, the state is moved to idle

• The BGP session is established
• BGP neighbor exchange routes via update messages
• Update and keepalive messages reset the hold timer
• If the hold timer expires, an error is detected BGP moves the neighbor back to the idle state

page 419