[FROG] FRR BGP Route Server Issues/Questions

[Donald Sharp]

Responses inline.

On Wed, Mar 25, 2020 at 10:58 AM Michael Lambert <lambert at psc.edu> wrote:
>
> We're running quagga (currently the Euro-IX fork, to be specific) as a
> route server.  I was hoping to be able to use FRR as a more-or-less
> drop-in replacement.  However, I've come up with some oddities which
> make me question whether route server functionality is still supported
> under FRR's bgpd.
>
> It appears that
>
>         neighbor <...> route-map <...> (import | export)
>
> has disappeared from the CLI.  I couldn't find anything obvious about
> this from either the git logs or the mailing list archive (but I have
> not done a bisection to figure out where they disappeared).  Are import
> <=> in and export <=> out the new mapping?  Or is it reversed?  There
> was always something not quite intuitive about import/export.  The
> documentation still refers to import/export, by the way.

We need to fix the documentation.  I'll submit a PR today hopefully.
This was changed in commit:

commit 2a3d57318c315aca75d54f93037e2fe52de30569 (HEAD, refs/bisect/bad)
Author: Daniel Walton <dwalton at cumulusnetworks.com>
Date:   Tue Nov 10 15:29:12 2015 +0000

    BGP: route-server will now use addpath...chop the _rsclient code

    Signed-off-by: Daniel Walton <dwalton at cumulusnetworks.com>
    Reviewed-by:   Donald Sharp <sharpd at cumulusnetworks.com>

import was equivalent to `in` and export was equivalent to `out`
We saw no reason to have in|import or out|export and simplfied
this code.

>
> I've setup a (virtual) lab environment with FRR's bgpd running under
> FreeBSD 12.1 and three BGP speakers running OpenBGPd under OpenBSD 6.6.
> When configuring FRR's bgpd with
>
>         neighbor <...> route-server-client
>
> the OpenBGPd speakers hear the expected routes from the route server,
> but with the route server itself as the next-hop.  If I include
>
>         neighbor <...> attribute-unchanged next-hop
>
> the next-hop is correctly propagated, but its presence would, on the
> surface, seem to make specifying "route-server-client" syntactic fluff.
>
> I also see that the
>
> show bgp [view <name>] (ipv4|ipv6) (unicast|multicast) rsclient <...>
>
> commands have disappeared, so the "obvious" way of checking route server
> functionality from within bgpd has, at best, changed.
>

show bgp ipv4 uni neighbor A.B.C.D routes|received-routes|received

are the commands you want now I believe.  If these are not sufficient
let me know what you want and let's see if we can get something reasonable
in.

> Assuming that the intent is to continue to support route server
> functionality within FRR, I have a couple of questions.  Is my approach
> of specifying route-server-client/attribute-unchanged correct or am I
> missing something that makes FRR's bgpd work like quagga's bgpd?  And
> are there plans to update the route server documentation to match the
> current implementation?  We've been using bgpd for many years; I'd like
> to continue doing so with a non-orphaned version.

I'm not sure what to recommend you do here as that this is normal EBGP behavior
and should be expected.  We do not have enough data about your setup to fully
recommend anything.

We'd love to have you use FRR, Feel free to join our slack
(https://frrouting.org ) and click
on the slack button and I'll see what I can do to help you get up and running.

donald
>
> Thanks,
>
> Michael
>
> --
> Michael H Lambert, GigaPoP Manager             Phone: +1 412 268-4960
> Pittsburgh Supercomputing Center/3ROX          FAX:   +1 412 268-5832
> 300 S Craig St, Pittsburgh, PA  15213 USA      lambert at psc.edu
>
>
> _______________________________________________
> frog mailing list
> frog at lists.frrouting.org
> https://lists.frrouting.org/listinfo/frog