EBGP to iBGP works with physical interfaces but not with loopback interfaces

[Amjad Abdullah]

Hi everyone

I am tampering with BGP learning it..and I came across this issue.

I am posting the network diagram below. EBGP need to run between ASs. OSPF and iBGP are running inside AS2.

Now, between AS1 and AS2 (same for AS2 and AS3), if I use loopback interfaces (static routes are configured for reachability) as the update source, the advertised networks (loopback1 in my case) appears only in first router in AS2 and "show ip bgp 11.11.11.11" says that the IP 1.1.1.1 is inaccessible (It is already configured with a static route and appears clearly in the routing table and pingable from physical and loopback interfaces).

I am not able to understand why it says "inaccessible"!

I would expect the AS edge router of AS2 to know the route and pass it to other routers in AS2. I expect those other routers to complain about reachability. But I can see that the edge AS2 router itself is complaining and says the source is "inaccessible" although it can reach it by all means.

! This is AS1 router config
router bgp 1
 neighbor 2.2.2.2 remote-as 2
 neighbor 2.2.2.2 update-source Loopback0
 network 11.11.11.0 mask 255.255.255.0

 ! This is the relevant AS2 edge router config
router bgp 2
 neighbor 2.2.2.2 remote-as 2
 neighbor 2.2.2.2 update-source Loopback0

 Thanks for your help in advance.

Am

 

[jalejand]

Assuming that both R1 and R2 have static routes pointing to each other loopback. Are these neighbors configured for ebgp multihop? As you are using loopbacks as sources, the TTL must be increased to 2 to reach the neighbor loopback.

[Amjad Abdullah]

Thank you my friend. I have ttl-security configured for two hops. I tried to increase it also to 3 hops but it didn't work either.

[paul driver]

Hello

As you using static routing your need also static routes for the physical connectivity regards the transit network between AS1-AS2-AS3 - suggest instead use an IGP

Lastly as for "show ip bgp 11.11.11.11" says that the IP 1.1.1.1 is inaccessible" on the IBGP peering in A2, Then rtr2 would need to advertised itself as a next-hop for AS1 (neighbor 192.168.2x.x next-hop-self) because at present the reason these routes bgp is stating is inaccessible is it doesn't have a route to Rtr1-Rtr2 AS transit network

[Amjad Abdullah]

Thanks Paul for your reply. I didn't probably get your point (forgive my ignorance). So, I'll re-describe the situation below and you reply me based on this description. OK?

The router in AS1 has a static route to the loopback0 interface of router Witherspoon in AS2. so it knows how to reach it.

The router Witherspoon has a static route pointing to the loopback0 interface of router in AS1. So that should be OK (IMHO).

Now, the router Witherspoon can see the update of network 22.22.22.22 (I can see it in "show ip bgp"). That means the update is find and it reaches the router Whitherspoon without any problem. My problem is that the router Witherspoon marks this route as inaccessible and doesn't put it in the routing table. What I don't understand is what does it exactly mean by "not accessible"? How can the router 1.1.1.1 inaccessible? I can ping it successfully from the router Witherspoon (from both physical and loopback as a source).

What the word "inaccessible" here means then? Although it is proven to be reachable?

[paul driver]

Hello

---

@Amjad Abdullah wrote:

Now, the router Witherspoon can see the update of network 22.22.22.22 (I can see it in "show ip bgp").

shouldn't this be a 11.11.11.11 ?

Based on your topology this is what should occur assuming you do have established ebgp/ibgp peering-

The two routes have established a bgp peering session between each other based on their lo0 interfaces and the peering is up Now that connection is successful due to the fact both rtrs share a common subnet - 192.168.12.0/24 and know how to reach each others loopback 0 interface due to the static routes pointing to each other loopback0  via their related 192.168.12.0 /24 interface/ip address.

You then advertise the loopback 1 addresses into bgp and those prefixes are also show in the bgp and routing tables.of both rtrs bullock and witherspoon. and these should also be reachable due to the fact their advertised next-hop would be each rtrs related loopback0 address which of course each rtr prefix knows how to reach due to those static routes you have applied.

Now when you create a ibgp peering session say between witherspoon and diaz lets say via their connected subnets 192.168.23.0  diaz will also receive buloocks 11.11.11.11 prefix however this will show up in its bgp table  being inaccessible via 1.1.1.1 this is because these diaz does not peer with this subnet so doesn't know how to reach 1.1.1.1 

So for this route to become valid and be implemented into the route table of diaz , diaz will need a valid path for 1.1.1.1.

Now you can apply more statics routes on rtrs bullock/diaz, or use an underlying igp to accomplish this or you can just change any ebgp prefix(s) advertised by witherspoon towards diaz to use their connected subnet as a nexhop.

witherspoon
rtr bgp 2
neighbor 192.168.23.3 next-hop-self

Once this is done diaz will see 11,11,11,11 as being accessible via 192.168.23.2 and not 1.1.1.1 and as such will now have a valid next-hop address it can reach.and consequently 11.11.11.11 will be implemented in to the route table of diaz.

However one cavat to this would be that unless rtr bullock has a valid path towards 192.168.23.0 then diax wont receive any response back from bullock, hence its suggested to use an underlying igp for NLRI in bgp so the transit networks between the bgp rtrs are reachable.

So to summarize any route in bgp showing x.x.x.x (inaccessible) means that bgp of that rtr doesn't have a valid path to the advertised nexthop of the prefix its has received

[Amjad Abdullah]

---

@paul driver wrote:

So to summarize any route in bgp showing x.x.x.x (inaccessible) means that bgp of that rtr doesn't have a valid path to the advertised nexthop of the prefix its has received

---

Thanks Paul. You are absolutely correct. But my issue is with the router "witherspoon" itself. nex-hop-self should (or, is supposed to) fix the issue for other routers in AS2. But rtr witherspoon should have a valid route to network 11.11.11.11 in its bgp table simply because it has a static route for that one. Correct me if I am wrong?

And yes, I meant 11.11.11.11 in my previous post, not 22.22.22.22. Thanks for pointing that.

[paul driver]

Hello

---

@Amjad Abdullah wrote:

---

@paul driver wrote:

So to summarize any route in bgp showing x.x.x.x (inaccessible) means that bgp of that rtr doesn't have a valid path to the advertised nexthop of the prefix its has received

---

Thanks Paul. You are absolutely correct. But my issue is with the router "witherspoon" itself. nex-hop-self should (or, is supposed to) fix the issue for other routers in AS2. But rtr witherspoon should have a valid route to network 11.11.11.11 in its bgp table simply because it has a static route for that one. Correct me if I am wrong?

And yes, I meant 11.11.11.11 in my previous post, not 22.22.22.22. Thanks for pointing that.

---

Yes Witherspoon itself should have a valid bgp route to 11.11.11.11 via its next hop 1.1.1.1 providing you do have a valid path to 1.1.1.1 be it by a static or dynamic entry’s 

[Amjad Abdullah]

---

@paul driver wrote:

Hello

---

@Amjad Abdullah wrote:

---

@paul driver wrote:

So to summarize any route in bgp showing x.x.x.x (inaccessible) means that bgp of that rtr doesn't have a valid path to the advertised nexthop of the prefix its has received

---

Thanks Paul. You are absolutely correct. But my issue is with the router "witherspoon" itself. nex-hop-self should (or, is supposed to) fix the issue for other routers in AS2. But rtr witherspoon should have a valid route to network 11.11.11.11 in its bgp table simply because it has a static route for that one. Correct me if I am wrong?

And yes, I meant 11.11.11.11 in my previous post, not 22.22.22.22. Thanks for pointing that.

---

Yes Witherspoon itself should have a valid bgp route to 11.11.11.11 via its next hop 1.1.1.1 providing you do have a valid path to 1.1.1.1 be it by a static or dynamic entry’s 

---

Thank you Paul. Yes, 1.1.1.1 is accessible (I have static route configured). So, I wonder why it says "inaccessible" in 'show ip bgp'? I can ping 1.1.1.1! it also says "no best path' which makes me confused? Is there anything that prevents BGP table from accepting static routes?

I think the BGP updates work as expected, first rtr tells the other rtr (in a different AS) about the network 11.11.11.0, the router that receives the update add it to the BGP table but not to the  routing tabling claiming that the route to 1.1.1.1 is inaccessible (although it is accessible in terms of reachability).
I added a static route in witherspoon toward 11.11.11.11, but it still says "inaccessible" after clearing the bgp process :)

[Jon Marshall · Accepted solution]

I think this might be IOS and platform specific ie. you mention you are using 3640 IOS, see this thread where someone had the same issue with a 3660 but the configuration worked with a 7200 - 

https://learningnetwork.cisco.com/thread/32768

also for what it is worth I used your exact configuration in VIRL on IOSv devices and it works fine. 

Jon

[Amjad Abdullah]

I think you are correct. It looks a bug or something!

Thank you for your time testing the scenario and pointing out the same issue in learning network.

[Georg Pauwen]

Hello,

post the full configs of both the Bullock (AS1) and the Witherspoon (AS2) routers...

[Amjad Abdullah]

Thanks. I will do in the first change. I don't unfortunately have the config handy right now.

[Amjad Abdullah]

Here is the config of the two routers and some other output commands that you may find useful.

hostname Bullock
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.0
!         
interface Loopback1
 ip address 11.11.11.11 255.255.255.0
!         
interface FastEthernet0/0
 description toward Witherspoon
 ip address 192.168.12.1 255.255.255.0
 duplex auto
 speed auto
!         
router bgp 1
 no synchronization
 bgp log-neighbor-changes
 network 11.11.11.0 mask 255.255.255.0
 neighbor 2.2.2.2 remote-as 2
 neighbor 2.2.2.2 ttl-security hops 2
 no auto-summary
!         
no ip http server
no ip http secure-server
ip route 2.2.2.0 255.255.255.0 FastEthernet0/0

hostname Witherspoon
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.0
!         
interface FastEthernet0/0
 description Toward Bullock
 ip address 192.168.12.2 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet1/0
 ip address 192.168.24.2 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet2/0
 ip address 192.168.23.2 255.255.255.0
 duplex auto
 speed auto
!
router ospf 1
 log-adjacency-changes
 passive-interface FastEthernet0/0
 network 0.0.0.0 255.255.255.255 area 0
!
router bgp 2
 no synchronization
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 1
 neighbor 1.1.1.1 ttl-security hops 2
 neighbor 1.1.1.1 update-source Loopback0
 neighbor 3.3.3.3 remote-as 2
 neighbor 3.3.3.3 update-source Loopback0
 neighbor 4.4.4.4 remote-as 2
 neighbor 4.4.4.4 update-source Loopback0
 neighbor 5.5.5.5 remote-as 2
 neighbor 5.5.5.5 update-source Loopback0
 no auto-summary
!
no ip http server
no ip http secure-server
ip route 1.1.1.0 255.255.255.0 FastEthernet0/0

Witherspoon#sh ip bgp summary
BGP router identifier 2.2.2.2, local AS number 2

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
1.1.1.1         4     1      10       9        3    0    0 00:05:52        1
3.3.3.3         4     2      11      11        3    0    0 00:07:25        0
4.4.4.4         4     2      46      48        3    0    0 00:42:14        0
5.5.5.5         4     2      46      48        3    0    0 00:42:04        0
Witherspoon#

Witherspoon#sh ip bgp 11.11.11.11
BGP routing table entry for 11.11.11.0/24, version 0
Paths: (1 available, no best path)
  Not advertised to any peer
  1
    1.1.1.1 (inaccessible) from 1.1.1.1 (11.11.11.11)
      Origin IGP, metric 0, localpref 100, valid, external
Witherspoon#

Witherspoon#show ip route

C    192.168.12.0/24 is directly connected, FastEthernet0/0
     1.0.0.0/24 is subnetted, 1 subnets
S       1.1.1.0 is directly connected, FastEthernet0/0
     2.0.0.0/24 is subnetted, 1 subnets
C       2.2.2.0 is directly connected, Loopback0
     3.0.0.0/32 is subnetted, 1 subnets
O       3.3.3.3 [110/2] via 192.168.23.3, 00:12:17, FastEthernet2/0
O    192.168.45.0/24 [110/2] via 192.168.24.4, 00:12:17, FastEthernet1/0
     4.0.0.0/32 is subnetted, 1 subnets
O       4.4.4.4 [110/2] via 192.168.24.4, 00:12:18, FastEthernet1/0
C    192.168.24.0/24 is directly connected, FastEthernet1/0
     5.0.0.0/32 is subnetted, 1 subnets
O       5.5.5.5 [110/3] via 192.168.24.4, 00:12:18, FastEthernet1/0
                [110/3] via 192.168.23.3, 00:12:18, FastEthernet2/0
O    192.168.56.0/24 [110/3] via 192.168.24.4, 00:12:20, FastEthernet1/0
                     [110/3] via 192.168.23.3, 00:12:20, FastEthernet2/0
C    192.168.23.0/24 is directly connected, FastEthernet2/0
O    192.168.35.0/24 [110/2] via 192.168.23.3, 00:12:20, FastEthernet2/0
Witherspoon#