Regarding bgp neighborship basics

Question

For the neighbor relationship, the update source IP from router R1 must match the neighbor command on router R2, and vice versa

To test the above,I set up my lab with R1 and R2 to test the above.(refer the pic shown below)

R1#sho ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            1.1.1.1         YES manual up                    up
FastEthernet0/1            unassigned      YES unset  administratively down down
Loopback0                  11.11.11.11     YES manual up                    up
R1#
R1#
R1#sho run | sec router bgp
router bgp 1
 no synchronization
 bgp log-neighbor-changes
 neighbor 22.22.22.22 remote-as 2
 neighbor 22.22.22.22 ebgp-multihop 2
 no auto-summary
R1#


R1#sho ip route 22.22.22.22
Routing entry for 22.0.0.0/8
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 1.1.1.2
      Route metric is 0, traffic share count is 1

R1#sho ip bgp summary | b Neighbor
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
22.22.22.22     4     2      13      12        0    0    0 00:26:10 Active

For R2, i have

R2#sho ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            unassigned      YES unset  administratively down down
FastEthernet0/1            1.1.1.2         YES manual up                    up
Loopback0                  22.22.22.22     YES manual up                    up

R2#sho run | sec router bgp
router bgp 2
 no synchronization
 bgp log-neighbor-changes
 neighbor 11.11.11.11 remote-as 1
 neighbor 11.11.11.11 ebgp-multihop 2
 no auto-summary
R2#



R2#sho ip route 11.11.11.11
Routing entry for 11.0.0.0/8
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 1.1.1.1
      Route metric is 0, traffic share count is 1

R2#sho ip bgp summary | b Neighbor
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
11.11.11.11     4     1       6       7        0    0    0 00:17:27 Active
R2#

Q1:As you see, my BGP neighborship is stuck in active state.From what i understand, R1 expects the neighborship packets from R2 with a source-ip of 22.22.22.22 If you do sho ip route on R2 for 11.11.11.11, you see that it is learnt via 1.1.1.1 as static route. Therefore, the bgp neighborship packets sourced from R2 will use this egress source ip(1.1.1.2) Please confirm if my understanding is correct

Q2:I add the following on R2.

R2(config)#router bgp 2
R2(config-router)#ne
R2(config-router)#nei
R2(config-router)#neighbor 11.11.11.11 up
R2(config-router)#neighbor 11.11.11.11 update-source lo
R2(config-router)#neighbor 11.11.11.11 update-source loopback 0
R2(config-router)#end
R2#
*Mar  1 00:56:26.211: %SYS-5-CONFIG_I: Configured from console by console
R2#sho ip bgp summary | b Neighbor
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
11.11.11.11     4     1       6       7        0    0    0 00:35:17 Active
R2#
*Mar  1 00:56:37.107: %BGP-5-ADJCHANGE: neighbor 11.11.11.11 Up
R2#

The bgp neighborship now comes up. My question is- why does the neighborship not come up as seen in the first case?

Q3:Now i advertise a different loopback from R2 towards R1 as follows

R2(config-router)#do sho run int lo2
Building configuration...

Current configuration : 61 bytes
!
interface Loopback2
 ip address 222.222.222.222 255.255.0.0
end

R2(config)#router bgp 2
R2(config-router)#network 222.222.0.0 mask 255.255.0.0

Then on R1, i see the prefix received

R1#sho ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

C    1.0.0.0/8 is directly connected, FastEthernet0/0
S    22.0.0.0/8 [1/0] via 1.1.1.2
C    11.0.0.0/8 is directly connected, Loopback0
B    222.222.0.0/16 [20/0] via 22.22.22.22, 00:04:53
R1#

Q: R1 is learning 222.222.0.0 with a next hop of 22.22.22.22. Why is 22.22.22.22 the next-hop ?

Answer 1

OK - so there are a few things going on here and I'll try to address them in some approximate order.

1. There are two sub-variants of BGP - internal (iBGP) and external (eBGP). In the case of iBGP the ASN's of the two peers are identical. In the case of eBGP the two ASN's are different. In your example you're using eBGP. I mention this because a number of rules are different between eBGP and iBGP.

2. Most typically eBGP sessions occur between directly connected interfaces. In your example this would mean that R1 and R2 would peer to one another as 1.1.1.1 and 1.1.1.2 respectively (i.e. R1 has a neighbor statement to 1.1.1.2, R2 has its statement to 1.1.1.1). This works because each router can reach the other via a directly connected route. If you deleted the update-source and static route and simply peered the routers on their directly connected interfaces the peer would come up without any further configuration. Also - as an aside, if you have a point-to-point link use a /30 or /31 prefix rather than a /8.

3. It's possible to configure what's called multihop eBGP. This means peering two router interfaces that aren't directly connected. This requires that another route needs to be in place for the interfaces to be able to pass packets. When you changed the source of the sessions to loopbacks you needed the static routes in place to allow the session to come up. Typically the peering session will require an additional statement specifying the maximum number of IP hops for the session but since in this instance they're only a single hop apart it may not have been necessary (..although it used to be). This is also known as a recursive route - so a route received with a next-hop of the remote router's loopback will actually use the static route as a way of resolving the interface that a given packet will take (in this case 1.1.1.x).

4. By default for eBGP routes will be advertised with a next-hop of the peering address (unless specifically altered via a knob or route-map). This is one of the differences with iBGP where the next-hop address will be normally unchanged across peers unless configured to behave otherwise.

Answer 2

when you want to create neighbourship in BGP with loopbacks interface. you should change update-source to loopback IP address. what for?

because when you create neighborship with loopback interface and you did not change source IP address. both routers try to establish a TCP session with source IP of egress port. then router2 receive a message that the source IP is 1.1.1.1 and the destination IP is 22.22.22.22. but it wants to be a neighbor with 11.11.11.11 while it receives messages from 1.1.1.1.

Q3: in BGP you should perform recursive lookup for find a route to the destination. for example in B 222.222.0.0/16 [20/0] via 22.22.22.22, 00:04:53 first, you find 22.22.22.22 then you should see routing table for 22.22.22.22. that is: S 22.0.0.0/8 [1/0] via 1.1.1.2 so, your packets go from 1.1.1.2 to the destination. Good luck