Dell PowerSwitch S4128F-ON OS10 Enterprise Edition User Guide Release 10.4.1.0 - Page 295

In operations with other BGP peers, a BGP process uses a simple finite state machine consisting of six states-Idle, Connect, Active, OpenSent, OpenConfirm, and Established. For each peer-to-peer session, a BGP implementation tracks the state of the session. The BGP defines the messages that each peer exchanges to change the session from one state to another. Idle Connect Active OpenSent OpenConfirm Established BGP initializes all resources, refuses all inbound BGP connection attempts, and starts a TCP connection to the peer. Router waits for the TCP connection to complete and transitions to the OpenSent state if successful. If that transition is not successful, BGP resets the ConnectRetry timer and transitions to the Active state when the timer expires. Router resets the ConnectRetry timer to zero and returns to the Connect state. Router sends an Open message and waits for one in return after a successful OpenSent transition. Neighbor relation establishes and is in the OpenConfirm state after the Open message parameters are agreed on between peers. The router then receives and checks for agreement on the parameters of the open messages to establish a session. Keepalive messages exchange, and after a successful receipt, the router is in the Established state. Keepalive messages continue to send at regular periods. The keepalive timer establishes the state to verify connections. After the connection is established, the router sends and receives keepalive, update, and notification messages to and from its peer. Peer templates Peer templates allow BGP neighbors to inherit the same outbound policies. Instead of manually configuring each neighbor with the same policy, you can create a peer group with a shared policy that applies to individual peers. A peer template provides efficient update calculation with simplified configuration. Peer templates also aid in convergence speed. When a BGP process sends the same information to many peers, a long output queue may be set up to distribute the information. For peers that are members of a peer template, the information is sent to one place then passed on to the peers within the template. Route reflectors Route reflectors (RRs) reorganize the IBGP core into a hierarchy and allow route advertisement rules. Route reflection divides IBGP peers into two groups - client peers and nonclient peers. • If a route is received from a nonclient peer, it reflects the route to all client peers • If a route is received from a client peer, it reflects the route to all nonclient and client peers An RR and its client peers form a route reflection cluster. BGP speakers announce only the best route for a given prefix. RR rules apply after the router makes its best path decision. NOTE: Do not use RRs in forwarding paths - hierarchal RRs that maintain forwarding plane RRs could create route loops. Layer 3 295