Learn BGP Protocol: First Basic About BGP You Should Know
This blog is created for network security review, study and understanding about network related issues only!
The blog is mainly focus on Network Security Notes about Network, Network Security, Network Technology, Network Labs review related Cisco and Microsoft technology ,Network Threats, Types of Network Threats, Network Alerts, Enterprise Security Policy and Audits, Security Policy and Audits,Logical Security, Physical and Logical Security, Physical Security,Cisco Products Review, Microsoft Products review, Cisco Routers, Routers Security, Console Access, Telnet Access, Network Attack, Network Attack report, Network management, Anti-virus, Network Security with Anti-virus, and All About Network Security... Thanks for your visit!
Learn BGP Protocol: First Basic About BGP You Should Know
Border Gateway Protocol (BGP) is a standardized exterior gateway protocol designed to exchange routing and reachability information among autonomous systems (AS) on the Internet.
Border Gateway Protocol (BGP) is a standardized exterior gateway protocol designed to exchange routing and reachability information among autonomous systems (AS) on the Internet. The protocol is often classified as a path vector protocol but is sometimes also classed as a distance-vector routing protocol. The Border Gateway Protocol makes routing decisions based on paths, network policies, or rule-sets configured by a network administrator and is involved in making core routing decisions.
BGP may be used for routing within an autonomous system. In this application it is referred to as Interior Border Gateway Protocol, Internal BGP, or iBGP. In contrast, the Internet application of the protocol may be referred to as Exterior Border Gateway Protocol, External BGP, or EBGP.
- The current version of BGP is version 4 (BGP4 or BGP-4) codified in RFC 4271 since 2006.
- Version 4 of BGP has been in use on the Internet since 1994. The major enhancement in version 4 was support for Classless Inter-Domain Routing and use of route aggregation to decrease the size of routing tables.
- Most Internet service providers must use BGP to establish routing between one another (especially if they are multihomed). Compare this with Signaling System 7 (SS7), which is the inter-provider core call setup protocol on the PSTN.
- Very large private IP networks use BGP internally. An example would be the joining of a number of large OSPF (Open Shortest Path First) networks where OSPF by itself would not scale to size. Another reason to use BGP is multihoming a network for better redundancy, either to multiple access points of a single ISP or to multiple ISPs.
- BGP neighbors, called peers, are established by manual configuration between routers to create a TCP session on port 179. - 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). When it runs between different autonomous systems, it is called External BGP (EBGP or Exterior Border Gateway Protocol). 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. 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. The main difference between iBGP and eBGP peering is in the way routes that were received from one peer are propagated to other peers. For instance, new routes learned from an eBGP peer are typically redistributed to all other iBGP peers as well as all eBGP peers (if transit mode is enabled on the router). However, if new routes were learned on an iBGP peering, then they are re-advertised only to all other eBGP peers. These route-propagation rules effectively require that all iBGP peers inside an AS are interconnected in a full mesh. Filtering routes learned from peers, their transformation before redistribution to peers or before plumbing them into the routing table is typically controlled via route-maps mechanism. These are basically rules which allow the application of certain actions to routes matching certain criteria on either ingress or egress path. These rules can specify that the route is to be dropped or, alternatively, its attributes are to be modified. It is usually the responsibility of the AS administrator to provide the desired route-map configuration on a router supporting BGP.
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. For each peer-to-peer session, a BGP implementation maintains a state variable that tracks which of these six states the session is in. The BGP defines the messages that each peer should exchange in order to change the session from one state to another. The first state is the "Idle" state. In the "Idle" state, BGP initializes all resources, refuses all inbound BGP connection attempts and initiates a TCP connection to the peer. The second state is "Connect". In the "Connect" state, the router waits for the TCP connection to complete and transitions to the "OpenSent" state if successful. If unsuccessful, it starts the ConnectRetry timer and transitions to the "Active" state upon expiration. In the "Active" state, the router resets the ConnectRetry timer to zero and returns to the "Connect" state. In the "OpenSent" state, the router sends an Open message and waits for one in return in order to transition to the "OpenConfirm" state. Keepalive messages are exchanged and, upon successful receipt, the router is placed into the "Established" state. In the "Established" state, the router can send/receive: Keepalive; Update; and Notification messages to/from its peer.
- Idle State: Refuse all incoming BGP connections. Start the initialization of event triggers. Initiates a TCP connection with its configured BGP peer. Listens for a TCP connection from its peer. Changes its state to Connect. If an error occurs at any state of the FSM process, the BGP session is terminated immediately and returned to the Idle state. Some of the reasons why a router does not progress from the Idle state are: TCP port 179 is not open. A random TCP port over 1023 is not open. Peer address configured incorrectly on either router. AS number configured incorrectly on either router.
- Connect State: Waits for successful TCP negotiation with peer. BGP does not spend much time in this state if the TCP session has been successfully established. Sends Open message to peer and changes state to OpenSent. If an error occurs, BGP moves to the Active state. Some reasons for the error are: TCP port 179 is not open. A random TCP port over 1023 is not open. Peer address configured incorrectly on either router. AS number configured incorrectly on either router.
- Active State: If the router was unable to establish a successful TCP session, then it ends up in the Active state. BGP FSM tries to restart another TCP session with the peer and, if successful, then it sends an Open message to the peer. If it is unsuccessful again, the FSM is reset to the Idle state. Repeated failures may result in a router cycling between the Idle and Active states. Some of the reasons for this include: TCP port 179 is not open. A random TCP port over 1023 is not open. BGP configuration error. Network congestion. Flapping network interface.
- OpenSent State:BGP FSM listens for an Open message from its peer. Once the message has been received, the router checks the validity of the Open message. If there is an error it is because one of the fields in the Open message does not match between the peers, e.g., BGP version mismatch, the peering router expects a different My AS, etc. The router then sends a Notification message to the peer indicating why the error occurred. If there is no error, a Keepalive message is sent, various timers are set and the state is changed to OpenConfirm.
- OpenConfirm State: The peer is listening for a Keepalive message from its peer. If a Keepalive message is received and no timer has expired before reception of the Keepalive, BGP transitions to the Established state. If a timer expires before a Keepalive message is received, or if an error condition occurs, the router transitions back to the Idle state.
- Established State: In this state, the peers send Update messages to exchange information about each route being advertised to the BGP peer. If there is any error in the Update message then a Notification message is sent to the peer, and BGP transitions back to the Idle state. If a timer expires before a Keepalive message is received, or if an error condition occurs, the router transitions back to the Idle state.
- The BGP standard specifies a number of decision factors, more than are used by any other common routing process, for selecting NLRI (Network Layer Reachability Information) to go into the Loc-RIB (Routing Information Base). The first decision point for evaluating NLRI is that its next-hop attribute must be reachable (or resolvable). Another way of saying the next-hop must be reachable is that there must be an active route, already in the main routing table of the router, to the prefix in which the next-hop address is reachable. Next, for each neighbor, the BGP process applies various standard and implementation-dependent criteria to decide which routes conceptually should go into the Adj-RIB-In. The neighbor could send several possible routes to a destination, but the first level of preference is at the neighbor level. Only one route to each destination will be installed in the conceptual Adj-RIB-In. This process will also delete, from the Adj-RIB-In, any routes that are withdrawn by the neighbor. Whenever a conceptual Adj-RIB-In changes, the main BGP process decides if any of the neighbor's new routes are preferred to routes already in the Loc-RIB. If so, it replaces them. If a given route is withdrawn by a neighbor, and there is no other route to that destination, the route is removed from the Loc-RIB, and no longer sent, by BGP, to the main routing table manager. If the router does not have a route to that destination from any non-BGP source, the withdrawn route will be removed from the main routing table.
==>More to come about BGP protocol,Don't forget to check back later,thanks!
If you like this post, please subscribe below,thanks!
0 comments:
Post a Comment