Cisco Border Gateway Protocol (BGP) Overview.

CCNA 200-301

CCNA 200-301

CCNP Enterprise

CCNP Enterprise

CCNP Security

CCNP Security

CCIE Enterprise Lab

CCIE Enterprise Lab

CCIE Security Lab

CCIE Security Lab

CCNP Service Provider

CCNP Service Provider

CCNP Data Center

CCNP Data Center

CCNP Collaboration

CCNP Collaboration

CCIE DC Lab

CCIE DC Lab

ic_r
ic_l
Cisco Border Gateway Protocol (BGP) Overview.
images

AS the world moves into the 5G era, BGP is playing a significant role in networking. Although BGP is popular in the IT industry, it ‘s difficult to understand. SPOTO involves a further area in the IT industry, which will provide various and influential certification such as CCIE, CCNA, CCNP, AWS, CISSP, to assist you to march into the IT industry. SPOTO is a stepping stone to understand BGP. 

BGP is an external gateway protocol for communication between routers of different autonomous systems. BGP is a replacement for the old EGP used by ARPANET. RFC 1267 [Lougheed and Rekhter 1991] describes the third edition of BGP.

RFC 1268 [Rekhter and Gross 1991] describes how to use BGP on the Internet. Most of the descriptions for BGP below are from these two RFC documents. At the same time, the fourth edition of BGP was developed in 1993 (see RFC1467 [Topolcic 1993]) to support the CIDR that we will describe in Section 10.8.

The BGP system exchanges network reachable information with other BGP systems. This information includes all paths in the autonomous system AS through which data must be delivered to these networks. This information is sufficient to construct an autonomous system connection diagram. Then, you can delete the routing ring and formulate a routing strategy according to the connection diagram .

First, we divide IP datagrams in an autonomous system into local traffic and traffic. In an autonomous system, the local flow starts or ends in the autonomous system. That is, the host specified by its source IP address or sink IP address is located in the autonomous system. Other flow is called passing flow. One purpose of using BGP on the Internet is to reduce the passing flow.

Autonomous systems can be divided into the following types:

1) stub AS, which has only a single connection to other autonomous systems. stubAS has only local flow.

2) Multi-homed Autonomous System (multihomedAS), which has multiple connections with other autonomous systems but refuses to transmit flow.

3) Transfer Autonomous System (transitAS), which has multiple connections with other autonomous systems. Under some policy guidelines, it can transmit local flow and passing flow.

In this way, the overall topology of the Internet can be thought of as an interconnection of stub-autonomous systems, multi-interface autonomous systems, and transit autonomous systems. Fragment autonomous systems and multi-interface autonomous systems do not require the use of BGP - they exchange reachable information between autonomous systems by running EGP.

BGP allows the use of policy-based routing. The policy is defined by the autonomous system administrator and assigned to BGP through the configuration file. The policy is not part of the protocol, but the specified policy allows BGP to select the path when there are multiple optional paths and control the resend of the information. The routing strategy is related to political, security or economic factors.

The difference between BGP and RIP and OSPF is that BGP uses TCP as its transport layer protocol. A TCP connection is established between two systems running BGP, and then the entire BGP routing table is exchanged. From this time on, when the routing table changes, an update signal is sent.

BGP is a distance vector protocol, but unlike RIP (advertised to the destination address hop count), BGP enumerates the route to each destination address (the serial number of the autonomous system to the destination address). This eliminates some of the problems of distance vector protocols. Autonomous system identification is represented by a 16-bit number.

BGP detects the link or host failure of the TCP connection peer by periodically sending keepalive packets to its neighbors. The recommended time interval between the two messages is 30 seconds. The application layer's keepalive message is independent of TCP's keepalive option.