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 ?
Best Answer
OK - so there are a few things going on here and I'll try to address them in some approximate order.
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.
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.
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).
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.