BGP (Border Gateway Protocol)
BGP is considered a “Path Vector” routing protocol. BGP was not built to route within an Autonomous System (AS), but rather to route between AS’s. BGP maintains a separate routing table based on shortest AS Path and various other attributes, as opposed to IGP metrics like distance or cost
BGP Autonomous Systems are assigned an Autonomous System Number (ASN), which is a 16-bit number ranging from 1 – 65535. A specific subset of this range, 64512 – 65535, has been reserved for private (or internal) use
should be used under the following circumstances:
• Multiple connections exist to external AS’s (such as the Internet) via different providers.
• Multiple connections exist to external AS’s through the same provider, but connect via a separate CO or routing policy.
• The existing routing equipment can handle the additional demands.
BGP Neighbors
There are two types of BGP neighbor relationships:
• iBGP Peers – BGP neighbors within the same autonomous system.
• eBGP Peers – BGP neighbors connecting separate autonomous systems.
In the above figure, RouterB and RouterC in AS 200 would form an iBGP peer relationship. RouterA in AS 100 and RouterB in AS 200 would form an eBGP peering.
Once BGP peers form a neighbor relationship, they share their full routing table. Afterwards, only changes to the routing table are forwarded to peers. By default, BGP assumes that eBGP peers are a maximum of one hop away. This restriction can be bypassed using the ebgp-multihop option with the neighbor command (demonstrated later in this guide). iBGP peers do not have a hop restriction, and are dependent on the underlying IGP of the AS to connect peers together. By default, all iBGP peers must be fully meshed within the Autonomous System. A Cisco router running BGP can belong to only one AS. The IOS will only allow one BGP process to run on a router. The Administrative Distance for routes learned outside the Autonomous System (eBGP routes) is 20, while the AD for iBGP and locally-originated routes is 200.
BGP Peers Messages
BGP forms its peer relationships through a series of messages. First, an OPEN message is sent between peers to initiate the session. The OPEN message contains several parameters:
• BGP Version – must be the same between BGP peers
• Local AS Number
• BGP Router ID
KEEPALIVE messages are sent periodically (every 60 seconds by default) to ensure that the remote peer is still available. If a router does not receive a KEEPALIVE from a peer for a Hold-time period (by default, 180 seconds), the router declares that peer dead.
As a BGP peer session is forming, it will pass through several states.
• Idle – the initial BGP state
• Connect - BGP waits for a TCP connection with the remote peer. If successful, an OPEN message is sent. If unsuccessful, the session is placed in an Active state.
• Active – BGP attempts to initiate a TCP connection with the remote peer. If successful, an OPEN message is sent. If unsuccessful, BGP will wait for a ConnectRetry timer to expire, and place the session back in a Connect State.
• OpenSent – BGP has both established the TCP connection and sent an OPEN Message, and is awaiting a reply OPEN Message. Once it receives a reply OPEN Message, the BGP peer will send a KEEPALIVE message.
• OpenConfirm – BGP listens for a reply KEEPALIVE message.
• Established – the BGP peer session is fully established. UPDATE messages containing routing information will now be sent
BGP is considered a “Path Vector” routing protocol. BGP was not built to route within an Autonomous System (AS), but rather to route between AS’s. BGP maintains a separate routing table based on shortest AS Path and various other attributes, as opposed to IGP metrics like distance or cost
BGP Autonomous Systems are assigned an Autonomous System Number (ASN), which is a 16-bit number ranging from 1 – 65535. A specific subset of this range, 64512 – 65535, has been reserved for private (or internal) use
should be used under the following circumstances:
• Multiple connections exist to external AS’s (such as the Internet) via different providers.
• Multiple connections exist to external AS’s through the same provider, but connect via a separate CO or routing policy.
• The existing routing equipment can handle the additional demands.
BGP Neighbors
There are two types of BGP neighbor relationships:
• iBGP Peers – BGP neighbors within the same autonomous system.
• eBGP Peers – BGP neighbors connecting separate autonomous systems.
In the above figure, RouterB and RouterC in AS 200 would form an iBGP peer relationship. RouterA in AS 100 and RouterB in AS 200 would form an eBGP peering.
Once BGP peers form a neighbor relationship, they share their full routing table. Afterwards, only changes to the routing table are forwarded to peers. By default, BGP assumes that eBGP peers are a maximum of one hop away. This restriction can be bypassed using the ebgp-multihop option with the neighbor command (demonstrated later in this guide). iBGP peers do not have a hop restriction, and are dependent on the underlying IGP of the AS to connect peers together. By default, all iBGP peers must be fully meshed within the Autonomous System. A Cisco router running BGP can belong to only one AS. The IOS will only allow one BGP process to run on a router. The Administrative Distance for routes learned outside the Autonomous System (eBGP routes) is 20, while the AD for iBGP and locally-originated routes is 200.
BGP Peers Messages
BGP forms its peer relationships through a series of messages. First, an OPEN message is sent between peers to initiate the session. The OPEN message contains several parameters:
• BGP Version – must be the same between BGP peers
• Local AS Number
• BGP Router ID
KEEPALIVE messages are sent periodically (every 60 seconds by default) to ensure that the remote peer is still available. If a router does not receive a KEEPALIVE from a peer for a Hold-time period (by default, 180 seconds), the router declares that peer dead.
As a BGP peer session is forming, it will pass through several states.
• Idle – the initial BGP state
• Connect - BGP waits for a TCP connection with the remote peer. If successful, an OPEN message is sent. If unsuccessful, the session is placed in an Active state.
• Active – BGP attempts to initiate a TCP connection with the remote peer. If successful, an OPEN message is sent. If unsuccessful, BGP will wait for a ConnectRetry timer to expire, and place the session back in a Connect State.
• OpenSent – BGP has both established the TCP connection and sent an OPEN Message, and is awaiting a reply OPEN Message. Once it receives a reply OPEN Message, the BGP peer will send a KEEPALIVE message.
• OpenConfirm – BGP listens for a reply KEEPALIVE message.
• Established – the BGP peer session is fully established. UPDATE messages containing routing information will now be sent
No comments:
Post a Comment