Users Guide

● If you use eBGP to exchange routes with switches in an SFS environment, the router must directly connect to the switch or
switches present. You must use the interface IP to set up BGP peering.
NOTE: This behavior is applicable only to the S4100-ON series of switches.
● By default, routes that are learned on multiple paths to eBGP peers are advertised to IBGP peers with the next-hop local IP
address. This behavior allows for local repair of atomic failure of any external peers.
● Fast external failover is enabled by default. To disable or re-enable fast external failover, use the [no] fast-externalfallover
command. For the fast-external-fallover command to take effect on an established BGP session, you must reset the session
using the clear ip bgp {* | peer-ipv4-address | peer-ipv6-address} command.
● Enabling the BGP add-paths globally for all BGP neighbors is not supported (the add-path command in ROUTER-BGPv4-AF
or ROUTER-BGPv6-AF mode). To enable the BGP add-path for one neighbor, use the add-path command in ROUTERBGP-
NEIGHBOR-AF mode.
● When you redistribute OSPFv3 routes to BGP, including External Type-2 routes, the multi-exit discriminator (MED) attribute
is set to the OSPF route metric plus one instead of the OSPF route metric value.
● When you configure the bgp bestpath router-id ignore command, for non-best paths, the show ip bgp output displays
Inactive reason: Router ID.
● Do not configure the IP address of the router as a BGP neighbor. This action causes the address being accepted as an invalid
neighbor address.
Sessions and peers
A BGP session starts with two routers communicating using the BGP. The two end-points of the session are called peers. A peer
is also called a neighbor. Events and timers determine the information exchange between peers. BGP focuses on traffic routing
policies.
Sessions
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
BGP initializes all resources, refuses all inbound BGP connection attempts, and starts a TCP connection
to the peer.
Connect 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.
Active Router resets the ConnectRetry timer to zero and returns to the Connect state.
OpenSent Router sends an Open message and waits for one in return after a successful OpenSent transition.
OpenConfirm 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.
Established 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 a 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.
612
Layer 3