Implementing a BGP Solution for ISP Connectivity

BGP Characteristics

    BGP Is Carried Inside TCP Segments, Which Are Inside IP Packets.

    It uses TCP to handle the acknowledgment function. TCP uses a dynamic window, which allows for up to 65,576 bytes to be outstanding before it stops and waits for an acknowledgment. For example, if 1000-byte packets are being sent and the maximum window size is being used, BGP would have to stop and wait for an acknowledgment only when 65 packets had not been acknowledged.

    TCP is designed to use a sliding window, where the receiver sends an acknowledgment before the number of octets specified by the window have been received (such at the halfway point of the sending window). This method allows any TCP application, such as BGP, to continue streaming packets without having to stop and wait, as OSPF or EIGRP would require.


    The BGP synchronization rule states that a BGP router should not use, or advertise to an external neighbor, a route learned by IBGP, unless that route is local or is learned from the IGP. In other words, BGP and the IGP must be synchronized before networks learned from an IBGP neighbor can be used.

    Synchronization should be enabled if there are routers in the BGP transit path in the autonomous system that are not running BGP (and therefore the routers do not have fullmesh IBGP within the autonomous system).


  • BGP table
  • BGP topology table
  • BGP topology database
  • BGP routing table
  • BGP forwarding database

    Message Types:

  • Open
  • Keepalive
  • Update
  • Notification

    Keepalive messages have a length of 19 bytes. Other messages may be between 19 and 4096 bytes long.

    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 message is sent back by the side that received the open message. Keepalive packets are sent to ensure that the connection is alive between the BGP peers, and notification packets are sent in response to errors or special conditions.

    An open message includes the following information:

  • Version - This 8-bit field indicates the message’s BGP version number. The highest common version that both routers support is used. BGP implementations today use the current version, BGP-4.
  • My autonomous system - This 16-bit field indicates the sender’s autonomous system number. The peer router verifies this information; if it is not the autonomous system number expected, the BGP session is torn down.
  • Hold time - This 16-bit field indicates the maximum number of seconds that can elapse between the successive keepalive or update messages from the sender. Upon receipt of an open message, the router calculates the value of the hold timer to use with this neighbor by using the smaller of its configured hold time (which has a default of 180 seconds) and the hold time received in the open message.
  • BGP router identifier (router ID) - This 32-bit field indicates the sender’s BGP identifier. The BGP router ID is an IP address assigned to that router and is determined at startup. The BGP router ID is chosen the same way the OSPF router ID is chosen: It is the highest active IP address on the router, unless a loopback interface with an IP address exists, in which case it is the highest such loopback IP address. Alternatively, the router ID can be statically configured, overriding the automatic selection.
  • Optional parameters - A length field indicates the total length of the optional parameters field in octets. These parameters are Type, Length, and Value (TLV)-encoded. An example of an optional parameter is session authentication.

    An update message has information on one path only; multiple paths require multiple messages. All the attributes in the update message refer to that path, and the networks are those that can be reached through that path:

  • Withdrawn routes - A list of IP address prefixes for routes that are being withdrawn from service, if any.
  • Path attributes - The AS-path, origin, local preference, and so forth. Each path attribute includes the attribute type, attribute length, and attribute value (TLV). The attribute type consists of the attribute flags, followed by the attribute type code.
  • Network layer reachability information (NLRI) - A list of networks (IP address prefixes and their prefix lengths) that can be reached by this path.

BGP Attributes

    Path attributes fall into four separate categories:

  • Well-known mandator
  • Well-known discretionary
  • Optional transitive
  • Optional nontransitive

    Only optional transitive attributes might be marked as partial.

    BGP Path Attribute Format:

  • Attribute type, which consists of a 1-byte attribute flags field and a 1-byte attribute type code field
  • Attribute length
  • Attribute value

    The first bit of the attribute flags field indicates whether the attribute is optional or well known. The second bit indicates whether an optional attribute is transitive or nontransitive. The third bit indicates whether a transitive attribute is partial or complete. The fourth bit indicates whether the attribute length field is 1 or 2 bytes. The rest of the flag bits are unused and are set to 0.

    Well-Known Attributes:

    A well-known attribute is one that all BGP implementations must recognize and propagate to BGP neighbors.

  • Well-known mandatory attribute - A well-known mandatory attribute must appear in all BGP update messages.
    • AS-path
    • Next hop
    • Origin
  • Well-known discretionary attribute - A well-known discretionary attribute does not have to be present in all BGP update messages.
    • Local preference
    • Atomic aggregate
  • Optional transitive - BGP routers that do not implement an optional transitive attribute should pass it to other BGP routers untouched and mark the attribute as partial.
    • Aggregator
    • Community
  • Optional nontransitive - BGP routers that do not implement an optional nontransitive attribute must delete the attribute and must not pass it to other BGP routers.
    • Multiexit-discriminator (MED)

    BGP Attribute Type Codes Cisco uses the following attribute type codes:

  • Origin — Type code 1
  • AS-path — Type code 2
  • Next-hop — Type code 3
  • MED — Type Code 4
  • Local-preference — type code 5
  • Atomic-aggregate — type code 6
  • Aggregator — Type code 7
  • Community — Type code 8 (Cisco-defined)
  • Originator-ID — Type code 9 (Cisco-defined)
  • Cluster list — Type code 10 (Cisco-defined)

    The Origin Attribute.

  • IGP - The route is interior to the originating autonomous system. This normally happens when a network command is used to advertise the route via BGP. An origin of IGP is indicated with an i in the BGP table.
  • EGP - The route is learned via EGP. This is indicated with an e in the BGP table. EGP is considered a historic routing protocol and is not supported on the Internet because it performs only classful routing and does not support CIDR.
  • Incomplete - The route’s origin is unknown or is learned via some other means. This usually occurs when a route is redistributed into BGP. An incomplete origin is indicated with a ? in the BGP table.

    The Local Preference Attribute

    Indicates to routers in the autonomous system which path is preferred to exit the autonomous system. A path with a higher local preference is preferred.

    The Community Attribute

    BGP communities are one way to filter incoming or outgoing routes. BGP communities allow routers to tag routes with an indicator (the community) and allow other routers to make decisions based on that tag.

    The MED Attribute

    The MED attribute, also called the metric. The MED indicates to external neighbors the preferred path into an autonomous system. This is a dynamic way for an autonomous system to try to influence another autonomous system as to which way it should choose to reach a certain route if there are multiple entry points into the autonomous system. A lower metric value is preferred

    The Weight Attribute

    The weight attribute is a Cisco-defined attribute used for the path-selection process. The weight attribute is configured locally and provides local routing policy only; it is not propagated to any BGP neighbors.

BGP Route-Selection Process

  1. Highest weight.
  2. Highest local preference
  3. Originated by the local router (next hop of in the BGP table.)
  4. Shortest AS-path
  5. Lowest-origin code (IGP < EGP < incomplete).
  6. Lowest MED.
  7. Prefer external paths (EBGP) over internal paths (IBGP).
  8. If synchronization is disabled (the default) and only internal paths remain, pre-
  9. fer the path through the closest IGP neighbor. This means that the router
  10. prefers the shortest internal path within the autonomous system to reach the
  11. destination (the shortest path to the BGP next hop).
  12. The oldest route
  13. Lowest neighbor BGP
  14. Lowest neighbor IP address.

Neighbor States

  • Idle - The router is searching the routing table to see whether a route exists to reach the neighbor.
  • Connect - The router found a route to the neighbor and has completed the three-way TCP handshake.
  • Open sent - An open message was sent, with the parameters for the BGP session.
  • Open confirm - The router received agreement on the parameters for establishing a session. Alternatively, the router goes into active state if there is no response to the open message.
  • Established - Peering is established and routing begins.

Configuring BGP

Multiple Path Selection

    Without the maximum-paths command under the router bgp 65201 command on R1, there is only one path to in R1’s routing table. After the maximum-paths 2 command is added to the R1 BGP configuration, both paths appear in the IP routing table. However, only one path is still selected as the best in the BGP table (as indicated by the > symbol)

R1#show ip route bgp
B [20/0] via, 00:00:41
[20/0] via, 00:00:41
R1#show ip bgp
BGP table version is 3, local router ID is
Status codes: s suppressed, d damped, h history, * valid, > best, i ->internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network        Next Hop        Metric    LocPrf    Weight    Path
*>    0                   0         65301 i
*        0                   0         65301 i

Peer Groups

    A BGP peer group is a group of BGP neighbors of the router being configured that all have the same update policies. The neighbor peer-group-name peer-group router configuration command is used to create a BGP peer group. Neighbor ip-address peer-group peer-group-name router configuration command, is used to assign neighbors as part of the group after the group has been created. The clear ip bgp peer-group peer-group-name EXEC command is used to reset the BGP connections for all members of a BGP peer group.

Defining the Source IP Address

    Use the neighbor {ip-address | peer-group-name} update-source loopback interface-number router configuration  command to cause the router to use the address of the specified loopback interface as the source address for BGP connections to this neighbor.

EBGP Multihop

    Because IGP routing information is not exchanged with external peers, the router must by default point to a directly connected address for external neighbors. A loopback interface is never directly connected. Therefore, if you want to peer with a loopback interface instead, you have to add a static route to the loopback pointing to the physical address of the directly connected network (the next-hop address). You must also enable multihop EBGP, with the neighbor {ip-address | peer-group-name} ebgp-multihop [ttl] router configuration command.

Changing the Next-Hop Attribute

    The neighbor {ip-address | peer-group-name} next-hop-self router configuration command is used to force BGP to use the source IP address of the update as the next hop for each network it advertises to the neighbor.

Reset of BGP Sessions

Clear ip bgp * or clear ip bgp {neighbor-address} privileged EXEC command. Use the clear ip bgp {* | neighbor-address} [soft out] privileged EXEC command.

    Soft Reset of BGP Sessions Inbound.

  1. Using Stored Information. To use stored information, first enter the neighbor {ip-address} soft-reconfiguration inbound router configuration command to cause BGP to save all updates that were learned from the neighbor specified. When the inbound policy is changed, use the clear ip bgp {* | neighbor-address} soft in privileged EXEC command to cause the router to use the stored unfiltered table to generate new inbound updates (in other words, updates from neighbors).
  2. Dynamic Inbound Soft Reset. This new method requires no preconfiguration (the neighbor soft-reconfiguration inbound command is not required) and requires significantly less memory than the previous soft reset method for inboundrouting table updates. The clear ip bgp {* | neighbor-address} [soft in | in] privileged EXEC command is the only command required for this dynamic soft reconfiguration.

Received, sent, or filtered.

Leave a Comment: