BGP multihop delayed:Why loopback network is not learned?

Answered Question
Dec 3rd, 2009

Hi folks, very simple setup to confirm some basic concepts. R1 and R2 are connected via interfaces as shown below. Then I advertise the loopback0 via BGP network statement. My understanding is that this is iBGP, so the eBGP multihop command should not apply. Next-hop-self should not be relevant because routers are on same BGP AS.


So my question is, why these loopback networks are not learned by the neighbor routers? I am wondering if this could be a glitch or I am msising something.

R1 lo0=150.4.1.1/24              R2 lo0  150.4.2.2/24
R1 f1/0=155.4.0.1/24-------------R2 f1/0 155.4.0.2/24


BGP debugging is on
R1#
00:30:23: BGP: 150.4.2.2 multihop open delayed 15904ms (no route)

R1#show run | b bgp
router bgp 100
no synchronization
bgp log-neighbor-changes
network 150.4.1.0 mask 255.255.255.0  <== I advertise the loopback0 of R1 here. I do not understand how come R2 will not learn this route.
neighbor 150.4.2.2 remote-as 100
neighbor 150.4.2.2 update-source Loopback0

no auto-summary
!
R1#show ip route 150.4.2.0  

% Subnet not in table


R1#show ip bgp
BGP table version is 2, local router ID is 150.4.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 150.4.1.0/24     0.0.0.0                  0         32768 i


R1#show ip route
(supressed)

Gateway of last resort is not set

     155.4.0.0/24 is subnetted, 1 subnets
C       155.4.0.0 is directly connected, FastEthernet1/0
     150.4.0.0/24 is subnetted, 1 subnets
C       150.4.1.0 is directly connected, Loopback0
R1#show ip bgp summ
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
150.4.2.2       4   100       0       0        0    0    0 never    Active  <== R2 is a neighbor OK.
R1#
R1#show run int lo 0
Building configuration...

Current configuration : 63 bytes
!
interface Loopback0
ip address 150.4.1.1 255.255.255.0
end

R1#


R2#show run | b bgp
router bgp 100
no synchronization
bgp log-neighbor-changes
network 150.4.2.0 mask 255.255.255.0
neighbor 150.4.1.1 remote-as 100
neighbor 150.4.1.1 update-source Loopback0

no auto-summary
!
R2#show ip bgp
BGP table version is 2, local router ID is 150.4.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 150.4.2.0/24     0.0.0.0                  0         32768 i

R2#sh ip route
(supressed)

Gateway of last resort is not set

     155.4.0.0/24 is subnetted, 1 subnets
C       155.4.0.0 is directly connected, FastEthernet1/0
     150.4.0.0/24 is subnetted, 1 subnets
C       150.4.2.0 is directly connected, Loopback0

#show ip bgp summ
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down
150.4.1.1       4   100       0       0        0    0    0 never
R2#
Building configuration...

Current configuration : 63 bytes
!
interface Loopback0
ip address 150.4.2.2 255.255.255.0
end

I have this problem too.
0 votes
Correct Answer by Reza Sharifi about 7 years 1 week ago

So it seems that when I have loopbacks involved I should plan to advertise them via IGP before attempting to establish the neighbor relationship using such loopbacks (or of course use other method such static route or connect using interfaces, etc).

Yes, that is a good idea.  you should be able to ping each peering loopback address before even get the BGP going. This way you know your IP connectivity is good before you move on to configure BGP.  You can use static route or dynamic routing protocol to accomplish this

HTH

Reza

Correct Answer by Jon Marshall about 7 years 1 week ago

news2010a wrote:

Interesting that in this case the routes were not passed to

each other router via iBGP. The BGP network statement is there

advertising such loopback network on the respective routers. The respective loopback network is a directly connected loopback interface (that means it is in the ip routing table of the respective router). Yet it did not learn via iBGP. Very interesting behavior.

So it seems that when I have loopbacks involved I should plan to advertise them via IGP before attempting to establish the neighbor relationship using such loopbacks (or of course use other method such static route or connect using interfaces, etc).

Because when you use the update source loopback command that means that source address of the packet is set to the loopback.

So from R2s perspective, it receives a BGP open packet with a source address of the 150.4.1.1. Note that this is before any routes are exchanged, this is to setup a BGP session so routes can be exchanged. But R2 doesn't know about this network because there is no IGP running so it cannot establish a BGP session.

So the issue is not so much that it was not learned via IBGP it was that it never got to that stage of exchanging routes because a BGP session was never established.

Jon

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
marpina Thu, 12/03/2009 - 11:45

It seems the BGP session is still down. We have 2 possibles options here.

on this link include details about the neighbor is on Active status means

no routes to the neighbor address or is not reachable.

https://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080093fb8.shtml

1. used the physical interface IP address on the neighbor statement and remove "neighbor x.x.x.x  update-source Loopback0"

on each router.

2. If works, then enabled  any IGP (as ospf) or add static routes in order to be reach the loopback of each routers.

This link have further scenarios, maybe help you.

Best regards

Marcelino

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800c95bb.shtml

Reza Sharifi Thu, 12/03/2009 - 11:37

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
150.4.2.2       4   100       0       0        0    0    0 never    Active  <== R2 is a neighbor OK.

Active is not good. your neighbor relationship has not been established. 

Looking at your config you are peering

R1

neighbor 150.4.2.2 remote-as 100

and R2

neighbor 150.4.1.1 remote-as 100

In the above scenario, the address for each site has to be on the same subnet

see below

R1

neighbor 150.4.2.2 remote-as 100

and R2

neighbor 150.4.2.1 remote-as 100

HTH

Reza

Jon Marshall Thu, 12/03/2009 - 11:55

news2010a wrote:

Hi folks, very simple setup to confirm some basic concepts. R1 and R2 are connected via interfaces as shown below. Then I advertise the loopback0 via BGP network statement. My understanding is that this is iBGP, so the eBGP multihop command should not apply. Next-hop-self should not be relevant because routers are on same BGP AS.


So my question is, why these loopback networks are not learned by the neighbor routers? I am wondering if this could be a glitch or I am msising something.

R1 lo0=150.4.1.1/24              R2 lo0  150.4.2.2/24
R1 f1/0=155.4.0.1/24-------------R2 f1/0 155.4.0.2/24


BGP debugging is on
R1#
00:30:23: BGP: 150.4.2.2 multihop open delayed 15904ms (no route)

R1#show run | b bgp
router bgp 100
no synchronization
bgp log-neighbor-changes
network 150.4.1.0 mask 255.255.255.0  <== I advertise the loopback0 of R1 here. I do not understand how come R2 will not learn this route.
neighbor 150.4.2.2 remote-as 100
neighbor 150.4.2.2 update-source Loopback0

no auto-summary
!
R1#show ip route 150.4.2.0  

% Subnet not in table


R1#show ip bgp
BGP table version is 2, local router ID is 150.4.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 150.4.1.0/24     0.0.0.0                  0         32768 i


R1#show ip route
(supressed)

Gateway of last resort is not set

     155.4.0.0/24 is subnetted, 1 subnets
C       155.4.0.0 is directly connected, FastEthernet1/0
     150.4.0.0/24 is subnetted, 1 subnets
C       150.4.1.0 is directly connected, Loopback0
R1#show ip bgp summ
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
150.4.2.2       4   100       0       0        0    0    0 never    Active  <== R2 is a neighbor OK.
R1#
R1#show run int lo 0
Building configuration...

Current configuration : 63 bytes
!
interface Loopback0
ip address 150.4.1.1 255.255.255.0
end

R1#


R2#show run | b bgp
router bgp 100
no synchronization
bgp log-neighbor-changes
network 150.4.2.0 mask 255.255.255.0
neighbor 150.4.1.1 remote-as 100
neighbor 150.4.1.1 update-source Loopback0

no auto-summary
!
R2#show ip bgp
BGP table version is 2, local router ID is 150.4.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 150.4.2.0/24     0.0.0.0                  0         32768 i

R2#sh ip route
(supressed)

Gateway of last resort is not set

     155.4.0.0/24 is subnetted, 1 subnets
C       155.4.0.0 is directly connected, FastEthernet1/0
     150.4.0.0/24 is subnetted, 1 subnets
C       150.4.2.0 is directly connected, Loopback0

#show ip bgp summ
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down
150.4.1.1       4   100       0       0        0    0    0 never
R2#
Building configuration...

Current configuration : 63 bytes
!
interface Loopback0
ip address 150.4.2.2 255.255.255.0
end

Marlon

The reason it is not working is that R1 does not know how to get to the loopback of R2 and vice-versa.

So either run an IGP or

R1

==

ip route 150.4.2.2 255.255.255.255 155.4.0.2

R2

==

ip route 150.4.1.1 255.255.255.255 155.4.0.1

Jon

news2010a Thu, 12/03/2009 - 12:11

Interesting that in this case the routes were not passed to

each other router via iBGP. The BGP network statement is there

advertising such loopback network on the respective routers. The respective loopback network is a directly connected loopback interface (that means it is in the ip routing table of the respective router). Yet it did not learn via iBGP. Very interesting behavior.

So it seems that when I have loopbacks involved I should plan to advertise them via IGP before attempting to establish the neighbor relationship using such loopbacks (or of course use other method such static route or connect using interfaces, etc).

Correct Answer
Reza Sharifi Thu, 12/03/2009 - 12:17

So it seems that when I have loopbacks involved I should plan to advertise them via IGP before attempting to establish the neighbor relationship using such loopbacks (or of course use other method such static route or connect using interfaces, etc).

Yes, that is a good idea.  you should be able to ping each peering loopback address before even get the BGP going. This way you know your IP connectivity is good before you move on to configure BGP.  You can use static route or dynamic routing protocol to accomplish this

HTH

Reza

Correct Answer
Jon Marshall Thu, 12/03/2009 - 12:16

news2010a wrote:

Interesting that in this case the routes were not passed to

each other router via iBGP. The BGP network statement is there

advertising such loopback network on the respective routers. The respective loopback network is a directly connected loopback interface (that means it is in the ip routing table of the respective router). Yet it did not learn via iBGP. Very interesting behavior.

So it seems that when I have loopbacks involved I should plan to advertise them via IGP before attempting to establish the neighbor relationship using such loopbacks (or of course use other method such static route or connect using interfaces, etc).

Because when you use the update source loopback command that means that source address of the packet is set to the loopback.

So from R2s perspective, it receives a BGP open packet with a source address of the 150.4.1.1. Note that this is before any routes are exchanged, this is to setup a BGP session so routes can be exchanged. But R2 doesn't know about this network because there is no IGP running so it cannot establish a BGP session.

So the issue is not so much that it was not learned via IBGP it was that it never got to that stage of exchanging routes because a BGP session was never established.

Jon

Actions

This Discussion