In the OpenSent state, the router sends an Open message and waits for one in return in order to transition to the OpenConfirm state. In the Active state, the router resets the ConnectRetry timer to zero and returns to the Connect state. If unsuccessful, it starts the ConnectRetry timer and transitions to the Active state upon expiration.
In the Connect state, the router waits for the TCP connection to complete and transitions to the OpenSent state if successful. In the Idle state, BGP initializes all resources, refuses all inbound BGP connection attempts and initiates a TCP connection to the peer. The BGP defines the messages that each peer should exchange in order to change the session from one state to another. For each peer-to-peer session, a BGP implementation maintains a state variable that tracks which of these six states the session is in. In order to make decisions in its operations with peers, a BGP peer uses a simple finite state machine (FSM) that consists of six states: Idle Connect Active OpenSent OpenConfirm and Established. Increasingly, BGP is used as a generalized signaling protocol to carry information about routes that may not be part of the global Internet, such as VPNs. These families include the IPv4 (default), IPv6, IPv4/IPv6 Virtual Private Networks and multicast BGP. If the multiprotocol extensions to BGP are negotiated at the time of creation, the BGP speaker can prefix the Network Layer Reachability Information (NLRI) it advertises with an address family prefix. The action could be to drop the route, or it could be to modify some attributes of the route before inserting it in the routing table.ĭuring the peering handshake, when OPEN messages are exchanged, BGP speakers can negotiate optional capabilities of the session, including multiprotocol extensions and various recovery modes.
Each rule describes, for routes matching some given criteria, what action should be taken. This mechanism consists of a set of rules. How routes are propagated can be controlled in detail via the route-maps mechanism.
#ROUTE REFLECTOR FULL#
These route-propagation rules effectively require that all iBGP peers inside an AS are interconnected in a full mesh with iBGP sessions. New routes learned from an iBGP peer are re-advertised to all eBGP peers only.New routes learned from an eBGP peer are re-advertised to all iBGP and eBGP peers.The main difference between iBGP and eBGP peering is in the way routes that were received from one peer are typically propagated by default to other peers: Other deployment topologies are also possible, such as running eBGP peering inside a VPN tunnel, allowing two remote sites to exchange routing information in a secure and isolated manner. Routers on the boundary of one AS exchanging information with another AS are called border or edge routers or simply eBGP peers and are typically connected directly, while iBGP peers can be interconnected through other intermediate routers. When it runs between different autonomous systems, it is called External BGP ( eBGP or Exterior Border Gateway Protocol). When BGP runs between two peers in the same autonomous system (AS), it is referred to as Internal BGP ( iBGP or Interior Border Gateway Protocol). Among routing protocols, BGP is unique in using TCP as its transport protocol. A BGP speaker sends 19-byte keep-alive messages every 30 seconds (protocol default value, tunable) to maintain the connection.
#ROUTE REFLECTOR MANUAL#
It is also called the Multiprotocol Extensions which is Multiprotocol BGP (MP-BGP).īGP neighbors, called peers, are established by manual configuration among routers to create a TCP session on port 179. The new RFC allows BGP4 to carry a wide range of IPv4 and IPv6 "address families". The major enhancement was the support for Classless Inter-Domain Routing (CIDR) and use of route aggregation to decrease the size of routing tables. RFC 4271 corrected errors, clarified ambiguities and updated the specification with common industry practices. The current version of BGP is version 4 (BGP4), which was published as RFC 4271 in 2006.
IPv6 BGP was first defined in RFC 1654 in 1994, and it was improved to RFC 2283 in 1998. It was first described in 1989 in RFC 1105, and has been in use on the Internet since 1994. The Border Gateway Protocol was sketched out in 1989 by engineers on the back of "three ketchup-stained napkins", and is still known as the three-napkin protocol. 5.2 AS numbers depletion and 32-bit ASNs.2.2 Router connectivity and learning routes.
0 kommentar(er)
