BGP update-source loopback not peering

Version 1.3.0-epa3

It is my understanding that the following:

set protocols bgp <asn> neighbor <address|interface> disable-connected-check

would allow me to use the loopback address as the update-source for a BGP neighbor/peer but it won’t connect unless I set the update-source to the address on the interface I am peering over.

Totally basic BGP config:

show configuration commands | grep bgp
set protocols bgp 65001 address-family ipv4-unicast redistribute connected
set protocols bgp 65001 neighbor 10.10.18.1 remote-as '65018'
set protocols bgp 65001 neighbor 10.10.18.1 update-source '10.10.18.2'
set protocols bgp 65001 parameters

Hi @trendal,

disable-connected-check will allow peerings between directly connected eBGP peers using loopback addresses. I have never used this setup, as I always peered between then IP addresses (usually /31) on the p2p link between the two eBGP neighbors.

Other then that, set protocols bgp 65001 neighbor <n> update-source can either be an IP address or an interface name.

Hope that helps,
Christian

1 Like

I failed to mention I tried the disable-connected-check but it didn’t make it work.

The reason for this is we have a lot of routers with 2 paths between them, a primary and secondary radio link. So if you use the loopback addresses as the update-source then if a primary or secondary link goes down it doesn’t tear down the BGP session.

Are you perhaps missing “ebgp-multihop”?

No, that’s for when your peering IP is not directly connected. I did try it anyway, no change.

stupid question…but have both routers a route towards remote loopback IP address?

1 Like

I can’t say without setting it back up and double checking but as I recall yes. I did the most basic of setup. (loopback)(eth0) → ← (eth0)(loopback) Setup BGP on the eth0 interfaces and set update-source to loopback, doesn’t work, change update-source to eth0 and it works again.

Ok, it looks like that is not the case. If I set up that basic config again, then the obvious only routes in the routing table are the local loopback and the eth0, so no, there is not a route for the remote loopback address.

So what am I missing about how that is supposed to work?

Is that config use case relying on some other protocol like OSPF to have shared the remote loopback route to the router?

Do you have any firewall rules?
You can give the output of the command:
ping 10.10.18.1 source-address 10.10.18.2
We also need a network diagram (peers, link between them, IP-addresses)

r1 and r18 ethernet connected between eth0 and eth0

r1 config:

set interfaces ethernet eth0 address 10.10.18.2/30
set interfaces loopback lo address 10.254.1.1/32
set protocols bgp 65001 address-family ipv4-unicast redistribute connected
set protocols bgp 65001 neighbor 10.10.18.1 remote-as '65018'
set protocols bgp 65001 neighbor 10.10.18.1 update-source '10.254.1.1'

r18 config:

set interfaces ethernet eth0 address 10.10.18.1/30
set interfaces loopback lo address 10.254.18.1/32
set protocols bgp 65018 address-family ipv4-unicast redistribute connected
set protocols bgp 65018 neighbor 10.10.18.2 remote-as '65001'
set protocols bgp 65018 neighbor 10.10.18.2 update-source '10.254.18.1'

No firewall rules at all

vyos@vyos:~$ ping 10.10.18.1 source-address 10.10.18.2
PING 10.10.18.1 (10.10.18.1) from 10.10.18.2 : 56(84) bytes of data.
64 bytes from 10.10.18.1: icmp_seq=1 ttl=64 time=0.734 ms
64 bytes from 10.10.18.1: icmp_seq=2 ttl=64 time=0.612 ms
64 bytes from 10.10.18.1: icmp_seq=3 ttl=64 time=0.654 ms

Edit: As soon as I change just one side to use an update-source of the 10.10.18.0/30 net then it all works. I’m suspecting that @16again is right that it’s because there is no route to the loopback address of the other router that it won’t ever connect. Apparently using the loopback address for the update-source is only for when you have an underlying protocol sharing that route info.

Exactly to check the routes, I asked for a ping result :wink:
Great that everything works now!
Thanks for the example config, might be useful for someone

No actually everything doesn’t work. If I put the update-source back to the loopback addresses then the bgp session dies.

The ping you requested will work without BGP, it’s just 2 interfaces connected with IP address in same subnet.

Just to be clear, the config above does not advertise routes to each other, the bgp session is dead. You have to set the update-source away from the loopback address and use the eth0 address. Then bgp advertises the it’s routes to the other router.

I think you need to add this command to make eBGP work:
set protocols bgp <asn> neighbor <address|interface> ebgp-multihop <number>

To see BGP state:
sh ip bgp neighbors

I tried ebgp-multihop 2 already, it doesn’t work.

sh ip bgp neighbors 10.10.18.2 
BGP neighbor is 10.10.18.2, remote AS 65001, local AS 65018, external link
  BGP version 4, remote router ID 0.0.0.0, local router ID 10.254.18.1
  BGP state = Active
  Last read 00:01:44, Last write never
  Hold time is 180, keepalive interval is 60 seconds
  Graceful restart information:
    Local GR Mode: Helper*
    Remote GR Mode: NotApplicable
    R bit: False
    Timers:
      Configured Restart Time(sec): 120
      Received Restart Time(sec): 0
  Message statistics:
    Inq depth is 0
    Outq depth is 0
                         Sent       Rcvd
    Opens:                  0          0
    Notifications:          0          0
    Updates:                0          0
    Keepalives:             0          0
    Route Refresh:          0          0
    Capability:             0          0
    Total:                  0          0
  Minimum time between advertisement runs is 0 seconds
  Update source is 10.254.18.1

 For address family: IPv4 Unicast
  Not part of any update group
  Community attribute sent to this neighbor(all)
  0 accepted prefixes

  Connections established 0; dropped 0
  Last reset 00:01:44,  Waiting for peer OPEN
  External BGP neighbor may be up to 2 hops away.
BGP Connect Retry Timer in Seconds: 120
Next connect timer due in 62 seconds
Read thread: off  Write thread: off  FD used: -1

I believe I found the answer on stackexchange

answer

Hi,
Does the bgp peering work eventually ?