02.10.2013 Views

FTOS Configuration Guide for the C-Series - Force10 Networks

FTOS Configuration Guide for the C-Series - Force10 Networks

FTOS Configuration Guide for the C-Series - Force10 Networks

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Establishing a session<br />

In<strong>for</strong>mation exchange between peers is driven by events and timers. The focus in BGP is on <strong>the</strong> traffic<br />

routing policies.<br />

In order to make decisions in its operations with o<strong>the</strong>r BGP peers, a BGP peer uses a simple finite state<br />

machine that consists of six states: Idle, Connect, Active, OpenSent, OpenConfirm, and Established. For<br />

each peer-to-peer session, a BGP implementation tracks which of <strong>the</strong>se six states <strong>the</strong> session is in. The<br />

BGP protocol defines <strong>the</strong> messages that each peer should exchange in order to change <strong>the</strong> session from one<br />

state to ano<strong>the</strong>r.<br />

The first state is <strong>the</strong> Idle mode. BGP initializes all resources, refuses all inbound BGP connection attempts,<br />

and initiates a TCP connection to <strong>the</strong> peer.<br />

The next state is Connect. In this state <strong>the</strong> router waits <strong>for</strong> <strong>the</strong> TCP connection to complete, transitioning<br />

to <strong>the</strong> OpenSent state if successful.<br />

If that transition is not successful, BGP resets <strong>the</strong> ConnectRetry timer and transitions to <strong>the</strong> Active state<br />

when <strong>the</strong> timer expires.<br />

In <strong>the</strong> Active state, <strong>the</strong> router resets <strong>the</strong> ConnectRetry timer to zero, and returns to <strong>the</strong> Connect state.<br />

Upon successful OpenSent transition, <strong>the</strong> router sends an Open message and waits <strong>for</strong> one in return.<br />

Keepalive messages are exchanged next, and upon successful receipt, <strong>the</strong> router is placed in <strong>the</strong><br />

Established state. Keepalive messages continue to be sent at regular periods (established by <strong>the</strong> Keepalive<br />

timer) to verify connections.<br />

Once established, <strong>the</strong> router can now send/receive Keepalive, Update, and Notification messages to/from<br />

its peer.<br />

Peer Groups<br />

Peer Groups are neighbors grouped according to common routing policies. They enable easier system<br />

configuration and management by allowing groups of routers to share and inherit policies.<br />

Peer groups also aid in convergence speed. When a BGP process needs to send <strong>the</strong> same in<strong>for</strong>mation to a<br />

large number of peers, it needs to set up a long output queue to get that in<strong>for</strong>mation to all <strong>the</strong> proper peers.<br />

If <strong>the</strong>y are members of a peer group, however, <strong>the</strong> in<strong>for</strong>mation can be sent to one place <strong>the</strong>n passed onto<br />

<strong>the</strong> peers within <strong>the</strong> group.<br />

Route Reflectors<br />

Route Reflectors reorganize <strong>the</strong> iBGP core into a hierarchy and allows some route advertisement rules.<br />

Route reflection divides iBGP peers into two groups: client peers and nonclient peers. A route reflector and<br />

its client peers <strong>for</strong>m a route reflection cluster. Since BGP speakers announce only <strong>the</strong> best route <strong>for</strong> a given<br />

prefix, route reflector rules are applied after <strong>the</strong> router makes its best path decision.<br />

<strong>FTOS</strong> <strong>Configuration</strong> <strong>Guide</strong>, version 7.7.1.0 463

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!