eBGP multihop neighbors

[stanislavsotak]

Hello,

I have a question regarding BGP. I have created a following topology.

I am trying to configure eBGP neighborship between routers FORD-2 and ISP-A1 via loopbacks, to make use of both physical links between them. My approach is to create static routes for one another's loopbacks, but I was curious how would it look if I created this neighborship by advertising their loopbacks into BGP and establishing relationship via ASN 209. I was able to do that and then I looked at the bgp route for 73.0.0.0/8 network from FORD-2:

 Can you please explain what exactly does the "inaccessible" here means for route via 30.0.0.1 [loopback of ISP-A1] ? And more importantly... is this why this path is not selected as best?

 Edit: I found out that the neighborship is rather unstable, and eventually it picked the route via 30.0.0.1 as the best. But I would still like to know what exactly does the "inaccessible" stands for here.

[MHM Cisco World]

...

[stanislavsotak]

Hi, yes that works. I just wanted if it would work with neighborship between FORD-2 and ISP-A1 established via FORD-1 -> ISP-B -> ISP-A2 -> ISP-A0 -> ISP-A1. So that works as well, but it seems not to be stable and I was wondering what is the meaning of "inaccessible" in the second screenshot. 

[MHM Cisco World]

...

[Georg Pauwen]

Hello,

post the configs of all routers involved in establishing the neighborship between FORD-2 and ISP-A1, otherwise it is just guesswork. What do you have configured between FORD-2 and ISP-A1 ? 165.33.10.4/30 and 165.33.10.8/30, meaning (e)BGP multipath ?

[Georg Pauwen]

Hello,

as I understand your topology, your eBGP neighbor is not directly connected ?

If that is the case, you need to disable the connected check, as, by default, a next hop needs to be directly connected for prefixes learnt from an eBGP neighbor.

neighbor 30.0.0.1 disable-connected-check

[MHM Cisco World]

disable-connected-check is only if the eBGP is direct connect but it use loopback.
he use multi hop so it ok.

[paul driver]

Hello @MHM Cisco World 

I don’t think the links being multi path differs for bgp will still try and source from it physical directly connected interfaces and you would still have to either specify update-source or use the disable-check when using loopback as peering 

[MHM Cisco World]

The disable-connected-check was created precisely for the purpose of peering two directly connected routers on their loopbacks without using the ebgp multihop.

So if ebgp is direct connect but use loopback "ofcourse as source " then we can use disable connected check, 

Otherwise we must use ebgp multi.

[paul driver]

Hello @MHM Cisco World 

---

@pauldriver 
I don’t think the links being multi path differs for bgp will still try and source from it physical directly connected interfaces and you would still have to either specify update-source or use the disable-check

---

[paul driver · Accepted solution]

Hello
What you have queried wouldn’t be a valid approach to peer the two rtrs - using static or an igp would be much more applicable

As for an bgp inaccessible route it means the advertised next-hop of the prefix isn’t reachable and no entry for it can be found with a rib lookup as such bgp is complains about it and won’t let the bgp route be entered in the local rib table 

Using the next-hop-self command on the igp-ebgp rtr could help clear that error

[MHM Cisco World]

your idea we is used in MP-BGP with some thing called PIC edge,

this need iBGP between the ISP router.

[MHM Cisco World]

So FORD-2 to reach ISP must pass FORD-1?

why instead config iBGP between FORD-2 and FORD-1 and FORD-2 automatic will learn route though FORD-1.

But make FORD-2 do other BGP session through same FORD-1 I don't see such this and I dent recommend.

[paul driver]

Hello

---

@MHM Cisco World wrote:

this need iBGP between the ISP router.

---

Not sure what you mean, as where IBGP is to be formed, Are you relating this to the OP original diagram if so they have ibgp peering already?

For use of PIC in this scenario,I would say PIC to be applied to the IBGP/EBGP CE rtrs and the internal IBGP rtr
Additional path on the internal ibgp rtr set to receive best path with default NHT (as BFD i wouldnt say have relevance here) and the CE rtrs advertise additional best path with BFD appended to their ebgp peering’s

However this is a totally new subject as the OP queried about bgp peering on loopbacks and inaccessible recursive route lookup