CCIE Study: BGP neighbors

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.

bgp-blog

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 3.3.3.3 remote-as 123
R3(config)#router bgp 123
R3(config-router)#neighbour 1.1.1.1 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: 3.3.3.3 open active, local address 10.1.2.1
*Mar  1 18:11:04.963: BGP: 3.3.3.3 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 1.1.1.1 not 10.1.2.1. 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 3.3.3.3 remote-as 123 for example. This will instruct BGP to send a packet with a destination IP of 3.3.3.3 and the source IP address will be the interface address. In our example this is 10.1.2.1. Our packet would look something like this

  • srcIP 10.1.2.1
  • dstIP 3.3.3.3
  • 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 1.1.1.1 and is receiving a source IP address of 10.1.2.1. An additional command will fix this.

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

Our packet would now look something like the following.

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

So lets breakdown the BGP debug. We firstly see debug for the neighbour relationship of 3.3.3.3. 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 3.3.3.3. 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 *

*