When we define a neighbor under BGP process, by default BGP uses the appropriate egress interface IP address to reach the neighbor. Once both the peers agree on the parameters the neighborship comes up.

If we want to build the neighborship over a specific interface IP address rather than the egress interface IP address, then we configure update source command. Normally we choose loopback interface for the BGP peering as it will be independent of the egress address if we have multiple exit interfaces to reach the remote peer.

We have been configuring the update source <interface> on both the peers respectively for the BGP neighborship to come up.

In this article lets discuss what will happen to the neighborship status if we miss the command on one of the peer.

BGP update source

To start with let’s have the command on both peers

R1
Interface loopback 1
Ip address 1.1.1.1 255.255.255.255
Interface loopback 11
Ip address 11.11.11.11 255.255.255.255
Interface eth 0/0
Ip add 10.10.12.1 255.255.255.0
no shut

router ospf 1
network 1.1.1.1 0.0.0.0 area 0
network 10.10.12.0 0.0.0.255 area 0

router bgp 100
bgp router-id 1.1.1.1
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 update-source loopback 1
network 11.11.11.11 mask 255.255.255.255

R2
Interface loopback 2
Ip address 2.2.2.2 255.255.255.255
Interface loopback 22
Ip address 22.22.22.22 255.255.255.255
Interface eth 0/0
Ip add 10.10.12.2 255.255.255.0
no shut

router ospf 1
network 2.2.2.2 0.0.0.0 area 0
network 10.10.12.0 0.0.0.255 area 0

router bgp 100
bgp router-id 2.2.2.2
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 update-source loopback 2
network 22.22.22.22 mask 255.255.255.255

Output from R1

R1#show ip bgp neighbors 2.2.2.2
<Snipped>
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 255
Local host: 1.1.1.1, Local port: 179
Foreign host: 2.2.2.2, Foreign port: 38415
Connection tableid (VRF): 0
Maximum output segment queue size: 50
<Snipped>

Now the BGP neighbor adjacency is up between the peers. R1 is acting as server as it is listening on port 179 and R2 is acting as client and communicating over port 38415.

Let’s remove the command on R2 and reset the BGP peering.

R2(config)#router bgp 100
R2(config-router)#no neighbor 1.1.1.1 update-source loopback 2
R2(config-router)#do clear ip bgp *
R2(config-router)#
*Dec 23 14:32:17.129: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Down User reset
*Dec 23 14:32:17.129: %BGP_SESSION-5-ADJCHANGE: neighbor 1.1.1.1 IPv4 Unicast topology base removed from session User reset
R2(config-router)#
*Dec 23 14:32:27.998: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up
R2(config-router)#
R2(config-router)#do show ip bgp sum
BGP router identifier 2.2.2.2, local AS number 100
BGP table version is 3, main routing table version 3
2 network entries using 288 bytes of memory
2 path entries using 120 bytes of memory
2/2 BGP path/bestpath attribute entries using 272 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 680 total bytes of memory
BGP activity 5/3 prefixes, 5/3 paths, scan interval 60 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
1.1.1.1 4 100 5 5 3 0 0 00:00:50 1
R2(config-router)#

Once we reset the BGP session, there will be again TCP negotiation between R1 & R2. Let’s check the status on R2.

R2 is acting as server as it is listening on port 179 and R1 is acting as client and communicating over port 32216.

R2#show ip bgp neighbors 1.1.1.1
<Snipped>
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 255
Local host: 2.2.2.2, Local port: 179
Foreign host: 1.1.1.1, Foreign port: 32216
Connection tableid (VRF): 0

But how did the BGP adjacency come up even we have removed the update source loopback 2 command from router R2 ?

It is because of the TCP protocol. BGP is more like an application running on TCP port 179 and does three-way handshake to form the session between client & servers (here the bgp neighbors).

When the BGP peer acting as TCP server (listens on port 179) receives a SYN request from any host, it only checks whether it has that neighbor defined or not. If the neighbor is defined and has a route to back to the peer address then it sends an ACK to proceed with further TCP connection steps.

So in other words the router which acts as a TCP server during BGP process only check the neighbor IP not the update-source config. The router acting as a client sends a SYN with using its update-source ip address and the router accepts that.

In our case R1 sent the syn to 2.2.2.2 with source ip as 1.1.1.1. In R2 we have defined 1.1.1.1 as a valid bgp neighbor, hence R2 accepts the TCP connection.

To validate this theory I enabled debug and cleared the BGP session on R2.

R2#
*Dec 23 14:48:58.967: BGP: 1.1.1.1 active went from Idle to Active
*Dec 23 14:48:58.967: BGP: 1.1.1.1 open active, local address 10.10.12.2
*Dec 23 14:48:58.968: BGP: 1.1.1.1 open failed: Connection refused by remote host
*Dec 23 14:48:58.968: BGP: 1.1.1.1 Active open failed - tcb is not available, open active delayed 13312ms (35000ms max, 60% jitter)
*Dec 23 14:48:58.968: BGP: ses global 1.1.1.1 (0xAFBA9680:0) act Reset (Active open failed).
*Dec 23 14:48:58.972: BGP: 1.1.1.1 active went from Active to Idle
*Dec 23 14:48:58.972: BGP: nbr global 1.1.1.1 Active open failed - open timer running
*Dec 23 14:48:58.972: BGP: nbr global 1.1.1.1 Active open failed - open timer running
R2#
*Dec 23 14:49:07.862: BGP: topo global:IPv4 Unicast:base Scanning routing tables
*Dec 23 14:49:07.862: BGP: Applying map to find origin for 22.22.22.22/32
*Dec 23 14:49:07.862: BGP: topo global:IPv4 Multicast:base Scanning routing tables
R2#
*Dec 23 14:49:09.037: BGP: 1.1.1.1 passive open to 2.2.2.2
*Dec 23 14:49:09.037: BGP: 1.1.1.1 passive went from Idle to Connect
*Dec 23 14:49:09.037: BGP: ses global 1.1.1.1 (0xAFBA9680:0) pas Setting open delay timer to 60 seconds.
*Dec 23 14:49:09.037: BGP: 1.1.1.1 passive rcv message type 1, length (excl. header) 38
*Dec 23 14:49:09.037: BGP: ses global 1.1.1.1 (0xAFBA9680:0) pas Receive OPEN
*Dec 23 14:49:09.037: BGP: 1.1.1.1 passive rcv OPEN, version 4, holdtime 180 seconds
*Dec 23 14:49:09.037: BGP: 1.1.1.1 passive rcv OPEN w/ OPTION parameter len: 28
*Dec 23 14:49:09.037: BGP: 1.1.1.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 6
*Dec 23 14:49:09.038: BGP: 1.1.1.1 passive OPEN has CAPABILITY code: 1, length 4
*Dec 23 14:49:09.038: BGP: 1.1.1.1 passive OPEN has MP_EXT CAP for afi/safi: 1/1
*Dec 23 14:49:09.038: BGP: 1.1.1.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Dec 23 14:49:09.038: BGP: 1.1.1.1 passive OPEN has CAPABILITY code: 128, length 0
*Dec 23 14:49:09.038: BGP: 1.1.1.1 passive OPEN has ROUTE-REFRESH capability(old) for all address-families
*Dec 23 14:49:09.038: BGP: 1.1.1.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Dec 23 14:49:09.038: BGP: 1.1.1.1 passive OPEN has CAPABILITY code: 2, length 0
*Dec 23 14:49:09.038: BGP: 1.1.1.1 passive OPEN has ROUTE-REFRESH capability(new) for all address-families
*Dec 23 14:49:09.038: BGP: 1.1.1.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Dec 23 14:49:09.038: BGP: 1.1.1.1 passive OPEN has CAPABILITY code: 70, length 0
*Dec 23 14:49:09.038: BGP: ses global 1.1.1.1 (0xAFBA9680:0) pas Enhanced Refresh cap received in open message
*Dec 23 14:49:09.038: BGP: 1.1.1.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 6
*Dec 23 14:49:09.038: BGP: 1.1.1.1 passive OPEN has CAPABILITY code: 65, length 4
*Dec 23 14:49:09.038: BGP: 1.1.1.1 passive OPEN has 4-byte ASN CAP for: 100
*Dec 23 14:49:09.038: BGP: nbr global 1.1.1.1 neighbor does not have IPv4 MDT topology activated
*Dec 23 14:49:09.038: BGP: 1.1.1.1 passive rcvd OPEN w/ remote AS 100, 4-byte remote AS 100
*Dec 23 14:49:09.038: BGP: ses global 1.1.1.1 (0xAFBA9680:0) pas Adding topology IPv4 Unicast:base
*Dec 23 14:49:09.038: BGP: ses global 1.1.1.1 (0xAFBA9680:0) pas Send OPEN
*Dec 23 14:49:09.038: BGP: ses global 1.1.1.1 (0xAFBA9680:0) pas Building Enhanced Refresh capability
*Dec 23 14:49:09.038: BGP: 1.1.1.1 passive went from Connect to OpenSent
*Dec 23 14:49:09.038: BGP: 1.1.1.1 passive sending OPEN, version 4, my as: 100, holdtime 180 seconds, ID 2020202
*Dec 23 14:49:09.038: BGP: 1.1.1.1 passive went from OpenSent to OpenConfirm
*Dec 23 14:49:09.044: BGP: 1.1.1.1 passive went from OpenConfirm to Established
*Dec 23 14:49:09.044: BGP: ses global 1.1.1.1 (0xAFBA9680:1) pas Assigned ID
*Dec 23 14:49:09.044: BGP: nbr global 1.1.1.1 Stop Active Open timer as all topologies are allocated
*Dec 23 14:49:09.044: BGP: ses global 1.1.1.1 (0xAFBA9680:1) Up
*Dec 23 14:49:09.044: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up
R2#

Initially (@ time Dec 23 14:48:58.967) R2 acted as client and sent the TCP sync to 1.1.1.1 with source address as its egress interface IP 10.10.12.2. R1 did not find 10.10.12.2 in its neighbor list hence sent TCP reset.

Subsequently R2 (@ time Dec 23 14:49:09.037) received  TCP sync from R1 to 2.2.2.2 with source IP as 1.1.1.1 (as R1 is still configured with update-source loopback 1 command). R2 checked its neighbor list and found 1.1.1.1 and accepted the TCP connection. Hence R2 acted as server and R1 as client in this TCP handshake.

Packet capture

BGP update source pcap

 

 

Thanks to my friend Rajesh Pillai who asked me this concept and I thought of explaining this here for wider audience.

 

 

 

3 thoughts on “Update-source ‘interface’ in BGP

  1. I tested a slightly different configuration.. R1 ——– R2, both R1 and R2 is having peering with directly connected IP address. but R2 is having additional update-source set to loopback0( this is not reqd in this case, but i added to see what happens to the session). Below is the configuration of the routers.
    TCP session initiated by R1 was successful, but right after the 3-way handshake, R1 sends the OPEN message, but R2 sends a RESET.(why?)

    according to the logic the update-source command on R2 should not have any effect as R1 initiate the TCP session. any thoughts? it seems post TCP session when R2 tries to send open message, it tries to use the update-source but as the session is built using the physical IP, it sends the RESET.

    R1#sh run int eth0/0
    interface Ethernet0/0
    ip address 192.168.12.1 255.255.255.0

    R1#sh run | s router bgp
    router bgp 1
    bgp log-neighbor-changes
    neighbor 192.168.12.2 remote-as 2
    ——————————————————————–
    R2#sh run int e0/0
    interface Ethernet0/0
    ip address 192.168.12.2 255.255.255.0

    R1#sh run int lo0
    interface Loopback0
    ip address 1.1.1.1 255.255.255.255

    R2#sh run | s router bgp
    router bgp 2
    bgp log-neighbor-changes
    neighbor 192.168.12.1 remote-as 1
    neighbor 192.168.12.1 update-source Loopback0

    Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s