Sunday, 23 October 2011

BGP

How Does BGP Work?

BGP uses TCP as the transport protocol, on port 179. Two BGP routers form a TCP connection between one another. These routers are peer routers. The peer routers exchange messages to open and confirm the connection parameters.
BGP routers exchange network reachability information. This information is mainly an indication of the full paths that a route must take in order to reach the destination network. The paths are BGP AS numbers. This information helps in the construction of a graph of ASs that are loop-free. The graph also shows where to apply routing policies in order to enforce some restrictions on the routing behavior.
Any two routers that form a TCP connection in order to exchange BGP routing information are "peers" or "neighbors". BGP peers initially exchange the full BGP routing tables. After this exchange, the peers send incremental updates as the routing table changes. BGP keeps a version number of the BGP table. The version number is the same for all the BGP peers. The version number changes whenever BGP updates the table with routing information changes. The send of keepalive packets ensures that the connection between the BGP peers is alive. Notification packets go out in response to errors or special conditions.

eBGP and iBGP

If an AS has multiple BGP speakers, the AS can serve as a transit service for other ASs. As the diagram in this section shows, AS200 is a transit AS for AS100 and AS300.
In order to send the information to external ASs, there must be an assurance of the reachability for networks. In order to assure network reachability, these processes take place:
  • Internal BGP (iBGP) peering between routers inside an AS
  • Redistribution of BGP information to IGPs that run in the AS
When BGP runs between routers that belong to two different ASs, this is called exterior BGP (eBGP). When BGP runs between routers in the same AS, this is called iBGP.
/image/gif/paws/26634/bgp-toc1.gif

Enable BGP Routing

Complete these steps in order to enable and configure BGP.
Assume that you want to have two routers, RTA and RTB, talk via BGP. In the first example, RTA and RTB are in different ASs. In the second example, both routers belong to the same AS.
  1. Define the router process and the AS number to which the routers belong.
    Issue this command to enable BGP on a router:
    router bgp autonomous-system
    RTA#
    router bgp 100
    
    RTB#
    router bgp 200
    These statements indicate that RTA runs BGP and belongs to AS100. RTB runs BGP and belongs to AS200.
  2. Define BGP neighbors.
    The BGP neighbor formation indicates the routers that attempt to talk via BGP.

Form BGP Neighbors

Two BGP routers become neighbors after the routers establish a TCP connection between each other. The TCP connection is essential in order for the two peer routers to start the exchange of routing updates.
After the TCP connection is up, the routers send open messages in order to exchange values. The values that the routers exchange include the AS number, the BGP version that the routers run, the BGP router ID, and the keepalive hold time. After the confirmation and acceptance of these values, establishment of the neighbor connection occurs. Any state other than Established is an indication that the two routers did not become neighbors and that the routers cannot exchange BGP updates.
Issue this neighbor command to establish a TCP connection:
neighbor ip-address remote-as number
The number in the command is the AS number of the router to which you want to connect with BGP. The ip-address is the next hop address with direct connection for eBGP. For iBGP, ip-address is any IP address on the other router.
The two IP addresses that you use in the neighbor command of the peer routers must be able to reach one another. One way to verify reachability is an extended ping between the two IP addresses. The extended ping forces the pinging router to use as source the IP address that the neighbor command specifies. The router must use this address rather than the IP address of the interface from which the packet goes.
If there are any BGP configuration changes, you must reset the neighbor connection to allow the new parameters to take effect.
  • clear ip bgp address
    Note: The address is the neighbor address.
  • clear ip bgp *
    This command clears all neighbor connections.
By default, BGP sessions begin with the use of BGP version 4 and negotiate downward to earlier versions, if necessary. You can prevent negotiations and force the BGP version that the routers use to communicate with a neighbor. Issue this command in router configuration mode:
neighbor {ip address | peer-group-name} version value
Here is an example of the neighbor command configuration:
/image/gif/paws/26634/bgp-toc2.gif
RTA#
router bgp 100
neighbor 129.213.1.1 remote-as 200

RTB#
router bgp 200
neighbor 129.213.1.2 remote-as 100
neighbor 175.220.1.2 remote-as 200

RTC#
router bgp 200
neighbor 175.220.212.1 remote-as 200
In this example, RTA and RTB run eBGP. RTB and RTC run iBGP. The remote AS number points to either an external or an internal AS, which indicates either eBGP or iBGP. Also, the eBGP peers have direct connection, but the iBGP peers do not have direct connection. iBGP routers do not need to have direct connection. But, there must be some IGP that runs and allows the two neighbors to reach one another.
This section provides an example of the information that the show ip bgp neighbors command displays.
Note: Pay special attention to the BGP state. Anything other than the state Established indicates that the peers are not up.
Note: Also, notice these items:
  • The BGP version, which is 4
  • The remote router ID
    This number is the highest IP address on the router or the highest loopback interface, if existent.
  • The table version
    The table version provides the state of the table. Any time that new information comes in, the table increases the version. A version that continues to increment indicates that there is some route flap that causes the continuous update of routes.
# show ip bgp neighbors
     BGP neighbor is 129.213.1.1, remote AS 200, external link 
     BGP version 4, remote router ID 175.220.12.1 
     BGP state = Established, table version = 3, up for 0:10:59 
     Last read 0:00:29, hold time is 180, keepalive interval is 60 seconds 
     Minimum time between advertisement runs is 30 seconds 
     Received 2828 messages, 0 notifications, 0 in queue 
     Sent 2826 messages, 0 notifications, 0 in queue 
     Connections established 11; dropped 10 

BGP and Loopback Interfaces

The use of a loopback interface to define neighbors is common with iBGP, but is not common with eBGP. Normally, you use the loopback interface to make sure that the IP address of the neighbor stays up and is independent of hardware that functions properly. In the case of eBGP, peer routers frequently have direct connection, and loopback does not apply.
If you use the IP address of a loopback interface in the neighbor command, you need some extra configuration on the neighbor router. The neighbor router needs to inform BGP of the use of a loopback interface rather than a physical interface to initiate the BGP neighbor TCP connection. In order to indicate a loopback interface, issue this command:
neighbor ip-address update-source interface
This example illustrates the use of this command:
/image/gif/paws/26634/bgp-toc3.gif
RTA# 
     router bgp 100 
     neighbor 190.225.11.1 remote-as 100 
     neighbor 190.225.11.1 update-source loopback 1 
RTB# 
     router bgp 100 
     neighbor 150.212.1.1 remote-as 100 
In this example, RTA and RTB run iBGP inside AS100. In the neighbor command, RTB uses the loopback interface of RTA, 150.212.1.1. In this case, RTA must force BGP to use the loopback IP address as the source in the TCP neighbor connection. In order to force this action, RTA adds update-source interface-type interface-number so that the command is neighbor 190.225.11.1 update-source loopback 1. This statement forces BGP to use the IP address of the loopback interface when BGP talks to neighbor 190.225.11.1.

0 comments: