2

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? enter image description here

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 ?

3

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.

  • thanks for detailed explaination,i want to reconfirm that update-source <interface name> command forces the TCP connection to be sourced with whatever <interface name> we specify ? R1 was expecting the TCP packets to hit with a source address of 22.22.22.22 ? Is that correct? Is that the reason my bgp neighborship was NOT UP until i gave update-source command on R2? – fsociety Jan 12 '17 at 6:57
  • 2
    Yes - update source tells the router which address to use for the neighbor's TCP session. The other side's neighbor statement should correspond to your update source. If you don't specify the update source then BGP will use the closest interface (as a function of local routes on the box). – rnxrx Jan 12 '17 at 7:06
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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.