BGP update source basics

Question

I have the following test lab:

The configuration of 'King' is:

King#sho ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            192.168.122.1   YES NVRAM  up                    up
Serial1/0                  192.168.112.1   YES NVRAM  up                    up
Serial1/1                  unassigned      YES NVRAM  administratively down down
Serial1/2                  unassigned      YES NVRAM  administratively down down
Serial1/3                  unassigned      YES NVRAM  administratively down down
Loopback0                  1.1.1.1         YES manual up                    up
King#
King#
King#sho run | sec bgp
router bgp 100
 no synchronization
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 100
 neighbor 2.2.2.2 update-source Loopback0
 no auto-summary
King#
King#sho run | sec eigrp
router eigrp 100
 network 0.0.0.0
 auto-summary
King#

The configuration of 'Kong' is:

Kong#sho ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            192.168.122.2   YES NVRAM  up                    up
Serial1/0                  192.168.112.2   YES NVRAM  up                    up
Serial1/1                  unassigned      YES NVRAM  administratively down down
Serial1/2                  unassigned      YES NVRAM  administratively down down
Serial1/3                  unassigned      YES NVRAM  administratively down down
Loopback0                  2.2.2.2         YES manual up                    up
Kong#
Kong#
Kong#sho run | sec bgp
router bgp 100
 no synchronization
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 100
 no auto-summary
Kong#
Kong#sho run | sec eigrp
router eigrp 100
 network 0.0.0.0
 auto-summary
Kong#

Question: From what i've read, i understood the following:

To establish a neighbor relationship, the update source IP from router A must match the neighbor command on router B, and vice versa.

However, in my case the update-source is configured on only 'King', how come the bgp neighbor ship is up?

Please explain in terms of packet flow.

Answer 1

To expand on @cown 's answer, the reason this works is because King initiated the connection, sending an open request to 2.2.2.2. Kong received the request on that interface, so it responded from from 2.2.2.2. If Kong had initiated the connection, it would looked up the best outgoing interface, (serial1/0 or 1/1) and used that as thesource. In that case, King would have received an open request from 192.168.122.2, and the BGP session would not have come up.

Answer 2

I will try to explain how the example works.

neighbor 2.2.2.2 remote-as 100

Here 2.2.2.2 is the intended destination of the BGP session.

When using:

neighbor 2.2.2.2 update-source Loopback0

We tell BGP to use IP source address of 1.1.1.1 with a destination of 2.2.2.2

If you don't specify the update-source the source will be that of the outgoing interface to 2.2.2.2 as in the IP routing table on the local-node (King).

However, BGP cannot know if you actually wish to peer your iBGP neighbor with a loopback address or just with the address of your physical interface that is used to reach that neighbor. Your network topology may be so simple that you have only one interface that goes towards your iBGP neighbor so in that case, requiring you to configure and advertise a loopback would simply be a formal and useless burden.

You can configure an iBGP neighbor by specifying any of it's existing IP addresses that is reachable. However, when you - as a router - decide which interface your BGP packet will go out off to reach the neighbor, that interface will be put into the packet's source IP address field.

So as for 'Kong':

As long as the path (via the physical FastEthernet and Serial) to the loopback interfaces exist, they will always be reachable.

By default, BGP will use the highest IP address assigned to a loopback interface as the BGP router-id. If there is no looback configured, BGP will use the highest IP address on any given interface.

neighbor 1.1.1.1 remote-as 100

Here the destination of 1.1.1.1 will be reached via the BGP session, in which BGP gives it the source IP address of 2.2.2.2.

Now consider the fact that you didn't have a loopback and your interfaces went up or down or the routing protocol information changed during an iBGP session, it may happen that you start sending your BGP packets to a particular peer from another outgoing interface than you originally used to establish the BGP session.

This would create peering problems, as the peering is bound to IP addresses of the neighbors, and if they change, the peering session will have to be reestablished from the scratch. The loopbacks here are helping you to maintain a stable pair of communicating IP addresses that do not depend on the state of actual physical interfaces or existing routes through an internetwork. Of course, the loopbacks must be reachable, i.e., the path to them must actually exist.

Conclusion is you should be able to use a loopback address as your IP source address when talking to a peer if you wish to do so, but you absolutely should not be forced to use it. This freedom of choice necessarily brings the special "neighbor update-source" command.