Maybe I missed the email, but I think Donald asked for a `show bgp next hop`, which I’m not seeing.

I would also suggest opening a bug report on our Github issue tracker (https://github.com/frrouting/frr/issues) for this as it’s more likely to get more attention there, where you can use things like code blocks, attachments, etc etc than here on the mailing list. I usually scrub my email inbox regularly but issues on GitHub stay there, available to the public and us, forever.

Quentin

On Apr 29, 2019, at 1:11 AM, Chris G <chris.g@euronet.space> wrote:

Hello,

Any idea please? It's a very frustrating bug and a very old one as well..

Chris

On 19.04.2019 15:33, Chris G wrote:
Hello,

Meanwhile I have tested several FRR versions using the official RPM packages available on the FRR website.

These FRR versions behave exactly the same. When the BGP session is configured inside a view, and there is no other non-view BGP session, FRR will not attempt to initiate a connection:
frr-5.0.2-001.el7.centos.x86_64.rpm
frr-6.0.2-01.el7.centos.x86_64.rpm
frr-7.0-01.el7.centos.x86_64.rpm

However, this version works as expected:
frr-4.0.1-2019010801.el7.centos.x86_64.rpm

FRRouting 4.0.1 (ts).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
configured with:
     '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--datadir=/usr/share' '--includedir=/usr/include' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sbindir=/usr/lib/frr' '--sysconfdir=/etc/frr' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var/run/frr' '--disable-werror' '--enable-irdp' '--enable-multipath=256' '--enable-vtysh' '--enable-ospfclient' '--enable-ospfapi=yes' '--enable-rtadv=yes' '--enable-ldpd' '--enable-pimd' '--enable-nhrpd' '--enable-eigrpd' '--enable-babeld' '--enable-user=frr' '--enable-group=frr' '--enable-vty-group=frrvty' '--enable-fpm' '--enable-watchfrr' '--disable-bgp-vnc' '--enable-isisd=yes' '--enable-systemd=yes' '--enable-poll=yes' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic' 'LDFLAGS=-Wl,-z,relro '

Is this a very old bug?

Kind regards,
Chris

On 18.04.2019 17:24, Donald Sharp wrote:
vtysh -c "show ver"

As well as `show bgp nexthop`

donald

On Thu, Apr 18, 2019 at 8:25 AM Chris G <chris.g@euronet.space> wrote:
Dear Christoffer,

Thank you for your reply!

I don't have access to my provider's BGP configuration I'm afraid.
However I am pasting my end of the setup below.

It might be relevant to note that the BGP instance is configure inside a
view, as I do not need anything to be installed in the main routing table.

I am using tcpdump to listen on the network interface for any traffic,
and FRR doesn't appear to be initiating any connections to my upstream.

My BGP config:

router bgp 65001 view ISP
   bgp router-id 192.168.255.227
   bgp log-neighbor-changes
   neighbor 192.168.255.225 remote-as 65000
   neighbor 192.168.255.225 description default
   neighbor 192.168.255.225 update-source 192.168.255.227
   neighbor 192.168.255.225 timers 10 30
   neighbor 192.168.200.29 remote-as 65000
   neighbor 192.168.200.29 description full-table
   neighbor 192.168.200.29 ebgp-multihop 255
   neighbor 192.168.200.29 update-source 192.168.255.227
   !
   address-family ipv4 unicast
    network 10.10.10.0/24
    neighbor 192.168.255.225 soft-reconfiguration inbound
    neighbor 192.168.255.225 weight 1000
    neighbor 192.168.255.225 prefix-list AS65001-export out
    neighbor 192.168.200.29 soft-reconfiguration inbound
    neighbor 192.168.200.29 weight 1000
    neighbor 192.168.200.29 prefix-list noexport out
   exit-address-family
!

Kind regards,
Chris

On 18.04.2019 12:58, Hansen, Christoffer wrote:
On 18/04/2019 10:21, Chris G wrote:
I have an issue where my BGP neighbor is configured in passive mode,
however my BGP (FRR 7.0) instance does not attempt to connect to this
neighbor.

Is this expected behavior? Is there any way I can force my BGP instance
to initiate a connection to the passive BGP neighbor ?
Could you provide the relevant neighbor configuration from both sides of
you BGP peering in this context?

_______________________________________________
frog mailing list
frog@lists.frrouting.org
https://lists.frrouting.org/listinfo/frog

_______________________________________________
frog mailing list
frog@lists.frrouting.org
https://lists.frrouting.org/listinfo/frog

_______________________________________________
frog mailing list
frog@lists.frrouting.org
https://lists.frrouting.org/listinfo/frog