12-03-2009 11:17 AM - edited 03-04-2019 06:52 AM
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
Solved! Go to Solution.
12-03-2009 12:16 PM
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
12-03-2009 12:17 PM
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
12-03-2009 11:37 AM
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
12-03-2009 11:45 AM
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
12-03-2009 11:55 AM
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 Loopback0no 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, ? - incompleteNetwork 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
endR1#
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 Loopback0no 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, ? - incompleteNetwork Next Hop Metric LocPrf Weight Path
*> 150.4.2.0/24 0.0.0.0 0 32768 iR2#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
12-03-2009 12:11 PM
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).
12-03-2009 12:16 PM
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
12-03-2009 12:17 PM
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
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: