Category Archives: 3.7.a Describe implement and troubleshoot peer relationships

3.7.a Describe implement and troubleshoot peer relationships

3.7.a [i] Peer-group, template

In older versions of Cisco IOS software, BGP update messages were grouped based on peer group configurations. This method of grouping neighbors for BGP update message generation reduced the amount of system processing resources needed to scan the routing table. This method, however, had the following limitations:

● All neighbors that shared the same peer group configuration also had to share the same outbound routing policies.

● All neighbors had to belong to the same peer group and address family. Neighbors configured in different address-families could not belong to different peer groups.

These limitations existed to balance optimal update generation and replication against peer group configuration. These limitations also caused the network operator to configure smaller peer groups, which reduced the efficiency of update message generation and limited the scalability of neighbor configuration.

A peer template is a configuration pattern that can be applied to neighbors that share common policies. Peer templates are reusable and support inheritance, which allows the network operator to group and apply distinct neighbor configurations for BGP neighbors that share common policies. Peer templates also allow the network operator to define very complex configuration patterns through the capability of a peer template to inherit a configuration from another peer template.

There are two types of peer templates:

● Peer session templates are used to group and apply the configuration of general session commands that are common to all address family and Network Layer Reachability Information (NLRI) configuration modes.

● Peer policy templates are used to group and apply the configuration of commands that are applied within specific address-families and NLRI configuration modes.

Peer templates improve the flexibility and enhance the capability of neighbor configuration. Peer templates also provide an alternative to peer group configuration and overcome some limitations of peer groups. With the configuration of the BGP Configuration Using Peer Templates feature and the support of the BGP Dynamic Update Peer-Groups feature, the network operator no longer needs to configure peer groups in BGP and can benefit from improved configuration flexibility and convergence.

Adam, Paul (2014-07-12). All-in-One CCIE V5 Written Exam Guide (Kindle Location 3747).  . Kindle Edition.

http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/s_bgpct.html#wp1037132

 

3.7.a Describe implement and troubleshoot peer relationships

3.7.a [ii] Active, passive

When a BGP speaker first initializes, it uses a local ephemeral TCP port, or random port number greater than 1024, and attempts to contact each configured BGP speaker on TCP port 179 (the well known BGP port). The speaker initiating the session performs an active open, while the peer performs a passive open. It’s possible for two speakers to attempt to connect to one another at the same time; this is known as a connection collision. When two speakers collide, each speaker compares the local router ID to the router ID of the colliding neighbor. The BGP speaker with the higher router ID value drops the session on which it is passive, and the BGP speaker with the lower router ID value drops the session on which it is active (i.e., only the session initiated by the BGP speaker with the larger router ID value is preserved).

Adam, Paul (2014-07-12). All-in-One CCIE V5 Written Exam Guide (Kindle Locations 3762-3766).  . Kindle Edition.

http://www.informit.com/articles/article.aspx?p=331613&seqNum=4

 

3.7.a Describe implement and troubleshoot peer relationships

  • 3.7.a [iii] States, timers

● 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, MD5 password 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.

BGP keepalive timer is 60 seconds and the hold-timer is 180 seconds. When a BGP connection negotiate the hold-timer between two BGP peers started, the smaller of the two hold-timers will be chosen. Internet is not a stable network, setting the hold-timer too low will be bad to router CPU as the route will keep on withdrawing and adding. We usually keep the BGP hold-timer as it is. However, if you use BGP in a stable WAN environment , you may choose to reduce the hold-timer for fast convergence.

Adam, Paul (2014-07-12). All-in-One CCIE V5 Written Exam Guide (Kindle Locations 3847-3850).  . Kindle Edition.

http://networkgeekstuff.com/networking/cisco-bgp-timers-re-explained/

3.7.a Describe implement and troubleshoot peer relationships

3.7.a [iv] Dynamic neighbors

BGP dynamic neighbor support allows BGP peering to a group of remote neighbors that are defined by a range of IP addresses. Each range can be configured as a subnet IP address. BGP dynamic neighbors are configured using a range of IP addresses and BGP peer groups.

After a subnet range is configured for a BGP peer group and a TCP session is initiated by another router for an IP address in the subnet range, a new BGP neighbor is dynamically created as a member of that group. After the initial configuration of subnet ranges and activation of the peer group (referred to as a listen range group ), dynamic BGP neighbor creation does not require any further CLI configuration on the initial router. Other routers can establish a BGP session with the initial router, but the initial router need not establish a BGP session to other routers if the IP address of the remote peer used for the BGP session is not within the configured range.

Adam, Paul (2014-07-12). All-in-One CCIE V5 Written Exam Guide (Kindle Locations 3851-3858).  . Kindle Edition.

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-3sg/irg-xe-3sg-book/irg-dynamic-neighbor.html