• Uses TCP as transport, port 179
  • Path vector protocol

Checks before becoming a neighbor

  • The TCP connection request must come from an IP associated with a neighbor command
  • The AS number must match that in the neighbore statement
  • The routers can not have duplicate router IDs
  • If authentication is configured it must also match


Uses a keepalive and hold timer, defaults to 60 and 180 seconds.

BGP neighbor states

Idle  –  BGP not initiated yet
Connect  – Listening for TCP
Active  – Initiate TCP
Open sent –  Open sent, TCP is up
Open confirm – Open receivec, TCP is up
Established – Peering has been established

BGP message types

Open  – Used to establish neighbor session and exchange parameters
Keepalive – Used to maintain the neighbor relationship
Update  – Used to exchange routing information
Notification – Used when BGP errors occur, resets neighbor session


  • Uses a sub ASN, real AS divided into smaller sections where each section has an private ASN
  • The range is from 64512 to 65535
  • Every sub-AS has to be fully meshed internally and uses iBGP logic
  • Connections between different sub AS acts as an EBGP connection
  • Confederation ASNs is not considered when deciding the AS-path length
  • Painful to migrate since it requires to change AS number in router bgp command
  • Real AS identified with bgp confederation identifier
  • Peers defined with bgp confederation peers
  • Confederation AS numbers in AS-path will be removed before advertising to true eBGP peer

Route reflectors

  • Removes the need for full mesh, all iBGP routers peer with route reflector
  • RR responsible for reflecting routes to clients, RR is usually not in forwarding path
  • No change is needed on clients to implement RR
  • The RR and its clients create a cluster, it is possible to have multiple RRs in a cluster
  • Route reflectors in different clusters should be fully meshed

To ensure no loops in this topology BGP needs two new attributes:

Cluster_list – Route reflectors add their cluster ID to this attribute before sending an update.   Updates with same cluster ID as local RR will be discarded.

Originator_ID – The ID of the router that originated the prefix. If a router sees its own ID in this  attribute it will not use or propagate this prefix.


AS_PATH   – Lists ASNs trough which the route has been advertised  –  Well known Mandatory
NEXT_HOP  – Lists the next-hop IP address used to reach the NLRI –  Well known Mandatory
AGGREGATOR  – Lists the RID and ASN of the router that created a summary NLRI – Optional Transitive
ATOMIC_AGGREGATE – Tags a summary NLRI as being a summary –  Well known Discretionary
ORIGIN  – The origin of the route, igp, egp or incomplete – Well known Mandatory
ORIGINATOR_ID  – The RID of the iBGP neighbor that injected a NLRI into the AS –  Optional Nontransitive
CLUSTER_LIST  – Used by RRs to lister the RR cluster IDs in order to prevent loops – Optional Nontransitive

Injecting routes into BGP

Done via network command or redistribute from an IGP or static routes.

Injecting a default route into BGP

Use the network command – Requires that exists in routing table
neighbor default-originate – Always advertise default route even if not present in local routing table
default-information originate – Requires route in routing table and a redistribute command

BGP best path algorithm

0. Discard routes with invalid next-hop
1. Routes with highest weight (Cisco proprietary)
2. Routes with highest local preference
3. Routes locally injected
4  Routes with shortest AS-path
5. Routes with best origin
6. Routes with lowest Multiple Exit Discriminator (MED)
7. Prefer eBGP over iBGP (confederation eBGP treated as iBGP)
8. Routes with lowest metric to next-hop

Border Gateway Protocol (BGP) – notes
Tagged on:         

4 thoughts on “Border Gateway Protocol (BGP) – notes

  • September 12, 2012 at 12:55 pm

    Hi reaper81 !
    “The routers can not have duplicate router IDs” => correct only with EBGP. In IBGP not correct.

    • September 12, 2012 at 1:12 pm


      When I test it I get errors for both iBGP and eBGP like this.

      %BGP-3-NOTIFICATION: received from neighbor 2/3 (BGP identifier wrong) 4 bytes 01010101

      • September 12, 2012 at 6:29 pm

        When i test it in GNS3 with IOS 3700. with iBGP everything is OK. but when i test in real Router, iBGP dont construct Neighbor.

  • November 6, 2014 at 7:47 pm

    Can anybody please reply on this?

    Same thing I am also getting :

    *Mar 1 00:46:21.631: %BGP-3-NOTIFICATION: sent to neighbor 2/3 (BGP identifier wrong) 4 bytes 78000001
    R6# FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 002D 0104 0064 00B4 7800 0001 1002 0601 0400 0100 0102 0280 0002 0202 00


Leave a Reply

Your email address will not be published. Required fields are marked *