I have been configuring a rather large topology within my GNS3 environment of late and it is composed of many peers. At this stage I had a plethora of peelings up. The diagram below highlights a small subset of a larger topology that I am using.


I have standard loopbacks which I generally use for peering. This is a simple iBGP peering running over the top of OSPF. Attempting to work through at a pace, on one such peering I put the following commands in to form the neighbour relationship.

R1(config)#router bgp 123
R1(config-router)# neighbour remote-as 123
R3(config)#router bgp 123
R3(config-router)#neighbour remote-as 123

The neighbour addresses are the addresses of the respective routers loopbacks. I prefer to use loopback addressing where possible as BGP peering is more resilient opposed to interface level peers. After a moment the peer didn’t come up (being a little impatient due to my self-imposed time restrictions) I immediately moved to debug.

R1#debug ip bgp 
*Mar  1 18:11:04.919: BGP: open active, local address
*Mar  1 18:11:04.963: BGP: open failed: Connection refused by remote host, open active delayed 34009ms (35000ms max, 28% jitter)

BGP configuration on R1 is sending the local-address to R3. R3 is looking to peer with not This poses a problem for BGP and the peering process as the connection is refused.

When the command configured to peer a BGP neighbour relationship is used it invokes a certain type of behaviour. Take the following command. Neighbour remote-as 123 for example. This will instruct BGP to send a packet with a destination IP of and the source IP address will be the interface address. In our example this is Our packet would look something like this

  • srcIP
  • dstIP
  • dstPort 179

While this is fine the neighbour there is a rule for BGP. The router must receive a TCP connection request with the source address found in the neighbour command. In our case, R3 is expecting a source IP of and is receiving a source IP address of An additional command will fix this.

R1(config)#router bgp 123
R1(config-router)#neigh update-source lo0

Our packet would now look something like the following.

  • srcIP
  • dstIP
  • dstPort 179
*Mar  1 18:11:37.595: BGP: passive open to
*Mar  1 18:11:37.595: BGP: went from Active to Idle
*Mar  1 18:11:37.595: BGP: went from Idle to Connect
*Mar  1 18:11:37.603: BGP: rcv message type 1, length (excl. header) 26
*Mar  1 18:11:37.603: BGP: rcv OPEN, version 4, holdtime 180 seconds
*Mar  1 18:11:37.603: BGP: went from Connect to OpenSent
*Mar  1 18:11:37.607: BGP: sending OPEN, version 4, my as: 123, holdtime 180 seconds
*Mar  1 18:11:37.607: BGP: rcv OPEN w/ OPTION parameter len: 16
*Mar  1 18:11:37.607: BGP: rcvd OPEN w/ optional parameter type 2 (Capability) len 6
*Mar  1 18:11:37.607: BGP: OPEN has CAPABILITY code: 1, length 4
*Mar  1 18:11:37.607: BGP: OPEN has MP_EXT CAP for afi/safi: 1/1
*Mar  1 18:11:37.607: BGP: rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar  1 18:11:37.607: BGP: OPEN has CAPABILITY code: 128, length 0
*Mar  1 18:11:37.607: BGP: OPEN has ROUTE-REFRESH capability(old) for all address-families
*Mar  1 18:11:37.607: BGP: rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar  1 18:11:37.607: BGP: OPEN has CAPABILITY code: 2, length 0
*Mar  1 18:11:37.607: BGP: OPEN has ROUTE-REFRESH capability(new) for all address-families 
*Mar  1 18:11:37.607: BGP: rcvd OPEN w/ remote AS 123
*Mar  1 18:11:37.611: BGP: went from OpenSent to OpenConfirm
*Mar  1 18:11:37.611: BGP: send message type 1, length (incl. header) 45
*Mar  1 18:11:37.631: BGP: went from OpenConfirm to Established
*Mar  1 18:11:37.631: %BGP-5-ADJCHANGE: neighbor Up 

So lets breakdown the BGP debug. We firstly see debug for the neighbour relationship of We move away from Active state which is a good sign. Into Idle state then immediate to connect. BGP is waiting to receive an Open message from It receives this message and path attributes are exchanged. As by the last two messages we move from OpenConfirm into Established. Debug reports an Adjacency change and neighbour 3.3.3 comes online.

Whilst this post stemmed from an incident of me not typing all the commands from my notepad it serves as a good reminder. It is great to understand how the CLI interprets your commands at the packet level. To understand what it means to put the command string in appended with update-source lo0 and how that effects the packet. I didn’t have any issue sorting out what was wrong but it serves as a timely remind as the march onwards to the CCIE continues that knowing how and why things operate the way they do are as important as ever.

Leave a Reply

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