Network Admin Stuff: Building iBGP Peering

Previous | Cisco | Next

Key points

BGP Protocol does not discover the neighboring routers running BGP (Peers). Administrator statically defines neighbor IP addresses for the BGP protocol to establish connection.

It uses TCP for transportation with destination port 179 (performs 3-way handshake)

Since BGP protocol uses TCP for transportation, the routers rely on IGP (OSPF/EIGRP/ISIS) to reach each other.

In an unlikely case both BGP peers initiated TCP session at exact same time, only the session originated by the higher BGP Router-ID is maintained. The other TCP session will be dropped.

An iBGP Peering (Internal BGP Peering) is built when the routers share the same AS number (Autonomous System number) which has certain consequences in relation to BGP operation.

If the routers forming BGP session do not share the same AS, they establish eBGP (External BGP) peering). There are some important differences between iBGP and eBGP operation (more on that in future labs).

Router allows only one AS to be configured.

BGP Router ID is chosen in the following order (the same as OSPF selection process):

Prefer, manually assigned Router ID.
If there is no manually assigned Router ID, use the highest IP address of configured Loopback interface.
If there is no manually configured Router ID, and no Loopback with configured IP address, use the highest IP address found on the physical interface.

Lab Topology

Here’s the R1 BGP configuration:

R1#conf t
R1(config)#router bgp 65100
R1(config-router)#bgp router-id 10.1.1.1
R1(config-router)#neighbor 172.16.14.4 remote-as 65100
R1(config-router)#end
R1#

In English this would, more or less, mean this:

Enter the global confiugation mode (conf t).

Start BGP process with AS number 65100 (router bgp 65100).

Manually assign BGP router id to be 10.1.1.1 (bgp router-id 10.1.1.1).

Initiate iBGP session to the IP address 172.16.14.4 (neighbor 172.16.14.4 remote-as 65100)

Get back to privileged mode (end).

What happens now with ‘neighbor 172.16.14.4 remote-as 65100’ statement, is that R1 is going to perform a routing table lookup trying to determine if it knows how to reach the neighbor. It does know the path to the neighbor as shown below:

R1#show ip route 172.16.14.4
Routing entry for 172.16.14.0/24
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via Ethernet0/0.14
      Route metric is 0, traffic share count is 1
R1#

Since this is a lab not a production equipment I can use all sorts of methods to inspect what’s happening behind the curtain. Let’s take a sneak peek using ‘debug ip tcp transactions’ enabled on both R1 and R4.

R1 Debug Output:

  
R1#debug ip tcp transactions
TCP special event debugging is on
R1#
TCBF316C348 created
TCBF316C348 setting property TCP_VRFTABLEID (20) F3ED29DC
TCBF316C348 setting property TCP_MD5KEY (4) 0
TCBF316C348 setting property TCP_ACK_RATE (37) F31765E8
TCBF316C348 setting property TCP_TOS (11) F3176604
TCBF316C348 setting property TCP_PMTU (45) F3176590
TCBF316C348 setting property TCP_IN_TTL (34) F31765A4
TCBF316C348 setting property TCP_OUT_TTL (35) F31765A4
TCBF316C348 setting property TCP_OUT_TTL (35) F3ED2BF2
TCBF316C348 setting property TCP_RTRANSTMO (36) F31765E4
TCP: Random local port generated 44659, network 1
TCBF316C348 bound to 172.16.14.1.44659
Reserved port 44659 in Transport Port Agent for TCP IP type 1
R1#
TCP: sending SYN, seq 2088596354, ack 0
TCP0: Connection to 172.16.14.4:179, advertising MSS 1460
TCP0: state was CLOSED → SYNSENT [44659 → 172.16.14.4(179)]
Released port 44659 in Transport Port Agent for TCP IP type 1 delay 240000
TCP0: state was SYNSENT  CLOSED [44659  172.16.14.4(179)]
TCP0: bad seg from 172.16.14.4 -- closing connection: port 44659 seq 0 ack 2088596355 rcvnxt 0 rcvwnd 0 len 0
TCP0: connection closed - remote sent RST
TCB 0xF316C348 destroyed
R1#u all
All possible debugging has been turned off

TCP block is created and bound to local IP 172.16.14.1, TCP source port 44659 is randomly chosen.

The source IP 172.16.14.1 is going to be used to communicate with the neighbor (IP address of the outgoing interface towards 172.16.14.4 - Ethernet0/0.14).

R1 is using TCP trying to establish session src: 172.16.14.1:44659 dst: 172.16.14.4:179.

This attempt fails due to TCP RST sent by 172.16.14.4. The reason RST is sen is that R4 has the port 179 currently closed. R4 BGP configuration is missing. TCP Control Block is destroyed. And shortly R1 is going to repeat the same process in an endless loop.

Let’s configure R4 to complete iBGP session with R1.

R4 - BGP Configuration:

  
router bgp 65104
 bgp router-id 10.4.4.4
 neighbor 172.16.14.1 remote-as 65104

Now, with proper BGP configuration on both devices, R1 shows the following output in the debug:

  

R1#debug ip tcp transactions 
TCP special event debugging is on
R1#
TCBF316C998 created
TCBF316C998 setting property TCP_VRFTABLEID (20) F3ED29DC
TCBF316C998 setting property TCP_MD5KEY (4) 0
TCBF316C998 setting property TCP_ACK_RATE (37) F3F83DA0
TCBF316C998 setting property TCP_TOS (11) F3F83DBC
TCBF316C998 setting property TCP_PMTU (45) F3F83D48
TCBF316C998 setting property TCP_RTRANSTMO (36) F3F83D9C
TCP: Random local port generated 24819, network 1
TCBF316C998 bound to 172.16.14.1.24819
Reserved port 24819 in Transport Port Agent for TCP IP type 1
TCP: sending SYN, seq 3941922061, ack 0
TCP0: Connection to 172.16.14.4:179, advertising MSS 1460
TCP0: state was CLOSED → SYNSENT [24819 → 172.16.14.4(179)]
TCP0: state was SYNSENT → ESTAB [24819 → 172.16.14.4(179)]
TCP: tcb F316C998 connection to 172.16.14.4:179, peer MSS 1460, MSS is 1460
TCBF316C998 connected to 172.16.14.4.179
TCBF316C998 setting property TCP_NO_DELAY (0) F3F83D9C
TCBF316C998 setting property TCP_RTRANSTMO (36) F3F83D9C
R1#
%BGP-5-ADJCHANGE: neighbor 172.16.14.4 Up 
R1#u all
All possible debugging has been turned off

And below is R4 output. Both are self-explanatory

R4#debug ip tcp transactions
TCP special event debugging is on
R4#
TCBF31AB410 created
TCBF31AB410 setting property TCP_PMTU (45) F31764C8
TCBF31AB410 setting property TCP_TOS (11) F31764F0
TCBF31AB410 setting property TCP_VRFTABLEID (20) F31AB0D4
TCBF31AB410 bound to 0.0.0.0.179
TCBF31AB410 setting property TCP_ACCESS_CHECK (5) 8F076F8
TCBF31AB410 setting property TCP_MD5KEY (4) 0
Reserved port 179 in Transport Port Agent for TCP IP type 1
TCBF31AB410 listening with queue 1

TCBF31C6948 created
TCP0: state was LISTEN → SYNRCVD [179 → 172.16.14.1(24819)]
TCP: tcb F31C6948 connection to 172.16.14.1:24819, peer MSS 1460, MSS is 516
TCP: sending SYN, seq 991876611, ack 3941922062
TCP0: Connection to 172.16.14.1:24819, advertising MSS 1460
TCP0: state was SYNRCVD → ESTAB [179 → 172.16.14.1(24819)]
TCBF31AB410 accepting F31C6948 from 172.16.14.1.24819
TCBF31C6948 setting property TCP_VRFTABLEID (20) F31AB0D4
TCBF31C6948 setting property TCP_PMTU (45) F3F0A150
TCBF31C6948 setting property TCP_NO_DELAY (0) F3F0A178
TCBF31C6948 setting property TCP_ACK_RATE (37) F3F0A180
TCBF31C6948 setting property TCP_RTRANSTMO (36) F3F0A178
%BGP-5-ADJCHANGE: neighbor 172.16.14.1 Up 
R4#
TCP0: ACK timeout timer expired
R4#u all
All possible debugging has been turned off

Another lab trick (do not attempt to use such debugs on the production equipment as they may crash), is to use ‘debug ip packet detail’ to see that exchange.

Here it is on R4:

R4(config)#access-list 100 permit tcp any host 172.16.14.1
R4(config)#access-list 100 permit tcp host 172.16.14.1 any

R4(config)#router bgp 65104
R4(config-router)#no neighbor 172.16.14.1
R4(config-router)#do debug ip packet detail 100
R4(config-router)#neighbor 172.16.14.1 remote-as 65104
R4(config-router)#end
R4#

This produces rather large output. But here is the gist:

  
R4#
FIBipv4-packet-proc: route packet from (local) src 172.16.14.4 dst 172.16.14.1
FIBfwd-proc: packet routed by adj to Ethernet0/0.14 172.16.14.1
FIBipv4-packet-proc: packet routing succeeded
IP: s=172.16.14.4 (local), d=172.16.14.1 (Ethernet0/0.14), len 44, sending
    TCP src=35036, dst=179, seq=3608906138, ack=0, win=16384 SYN
IP: s=172.16.14.4 (local), d=172.16.14.1 (Ethernet0/0.14), len 44, sending full packet
    TCP src=35036, dst=179, seq=3608906138, ack=0, win=16384 SYN
IP: s=172.16.14.1 (Ethernet0/0.14), d=172.16.14.4, len 44, rcvd 0
    TCP src=179, dst=35036, seq=2263598807, ack=3608906139, win=16384 ACK SYN
FIBipv4-packet-proc: route packet from (local) src 172.16.14.4 dst 172.16.14.1
FIBfwd-proc: packet routed by adj to Ethernet0/0.14 172.16.14.1
FIBipv4-packet-proc: packet routing succeeded
IP: s=172.16.14.4 (local), d=172.16.14.1 (Ethernet0/0.14), len 40, sending
    TCP src=35036, dst=179, seq=3608906139, ack=2263598808, win=16384 ACK

The take away from this TCP 3-way exchange is that R4 becomes a client, R1 is a server, and the TCP session has been established.

Here is the proof:

  
R4#show tcp brief
TCB       Local Address               Foreign Address             (state)
F31F82F0  172.16.14.4.35036           172.16.14.1.179              ESTAB
R4#

R4#show ip bgp neighbor 172.16.14.1
BGP neighbor is 172.16.14.1,  remote AS 65104, internal link
  BGP version 4, remote router ID 10.1.1.1
  BGP state = Established, up for 00:11:43
[snip]
Local host: 172.16.14.4, Local port: 35036
Foreign host: 172.16.14.1, Foreign port: 179
[snip]

The ‘internal link’ means it is an iBGP sessions. Both R1 and R4 share the same AS number 65104.

In the following output, notice two things:

State shows nothing (it means it is established)
PfxRcd (prefixes received) is 0

  
R4#show ip bgp summary
BGP router identifier 10.4.4.4, local AS number 65104
BGP table version is 1, main routing table version 1

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
172.16.14.1     4        65104      23      23        1    0    0 00:16:56        0
R4#

Unlike IGP routing protocols (OSPF/ISIS/EIGRP/RIP), BGP does not advertise any network prefixes. They will need to be advertised manually by the admin.

Network Admin Stuff

Saturday, July 18, 2020

Building iBGP Peering

Key points

Lab Topology

Cisco Is Easy - Main