FRR BGP Route Server Issues/Questions
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. 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. 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. 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@psc.edu
Responses inline. On Wed, Mar 25, 2020 at 10:58 AM Michael Lambert <lambert@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@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@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@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@psc.edu
_______________________________________________ frog mailing list frog@lists.frrouting.org https://lists.frrouting.org/listinfo/frog
Hi Donald, Thanks for your feedback; some more comments below. Donald Sharp wrote on 2020/03/26 08:48:22:
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.
The FRR behavior with route-server-client seems to be a change from the way it was handled in quagga. Perhaps this was discussed on the FRR mailing lists, but I haven't been able to track it down and I again don't see anything obvious in the changelogs. Based on previous behavior of quagga (and even going back to the RSd derivative of GateD in the mid-90s) my expectation is that an EBGP speaker operating in route server mode 1) would not install learned routes in its own FIB (FRR handles this correctly) and 2) would, unless explicitly overridden, pass BGP updates transparently between clients (FRR does not appear to do this, at least with next-hop). I'm not saying the FRR behavior is incorrect, just that it's unexpected. I'd be interested in hearing other's views on the preferred behavior of route-server-client.
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.
Thanks, I'll take you up on this next week. Michael
Michael - I submitted PR https://github.com/FRRouting/frr/pull/6104 to rectify this situation as you are expecting this to work. Let me know if you want to try it out and I'll point you at the .deb or .rpm to test it. donald On Fri, Mar 27, 2020 at 5:38 PM Michael Lambert <lambert@psc.edu> wrote:
Hi Donald,
Thanks for your feedback; some more comments below.
Donald Sharp wrote on 2020/03/26 08:48:22:
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.
The FRR behavior with route-server-client seems to be a change from the way it was handled in quagga. Perhaps this was discussed on the FRR mailing lists, but I haven't been able to track it down and I again don't see anything obvious in the changelogs. Based on previous behavior of quagga (and even going back to the RSd derivative of GateD in the mid-90s) my expectation is that an EBGP speaker operating in route server mode 1) would not install learned routes in its own FIB (FRR handles this correctly) and 2) would, unless explicitly overridden, pass BGP updates transparently between clients (FRR does not appear to do this, at least with next-hop).
I'm not saying the FRR behavior is incorrect, just that it's unexpected. I'd be interested in hearing other's views on the preferred behavior of route-server-client.
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.
Thanks, I'll take you up on this next week.
Michael
_______________________________________________ frog mailing list frog@lists.frrouting.org https://lists.frrouting.org/listinfo/frog
participants (2)
-
Donald Sharp -
Michael Lambert