bgpd: When acting as a RR server do not modify nexthop

https://lists.frrouting.org/pipermail/frog/2020-March/000776.html

It was pointed out that we are not properly passing the nexthop
through and instead we were replacing the nexthop as a Route Server
with our own.

https://tools.ietf.org/html/rfc4456#section-4

10.  Implementation Considerations
   Care should be taken to make sure that none of the BGP path
   attributes defined above can be modified through configuration when
   exchanging internal routing information between RRs and Clients and
   Non-Clients.  Their modification could potentially result in routing
   loops.
   In addition, when a RR reflects a route, it SHOULD NOT modify the
   following path attributes: NEXT_HOP, AS_PATH, LOCAL_PREF, and MED.
   Their modification could potentially result in routing loops.

Modify the code such that when FRR is instructed to act as a
Route-Server to pass through the nexthop.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>

diff --git a/bgpd/bgpd.c b/bgpd/bgpd.c
index 94527701009fa89deccff610b3a5006aa28fcddf..6534ac19000242fc7066ff1aa88898789866c649 100644 (file)
--- a/bgpd/bgpd.c
+++ b/bgpd/bgpd.c
@@ -4199,6 +4199,19 @@ static int peer_af_flag_modify(struct peer *peer, afi_t afi, safi_t safi,
                }
        }
 
+       /*
+        * If the peer is a route server client let's not
+        * muck with the nexthop on the way out the door
+        */
+       if (flag & PEER_FLAG_RSERVER_CLIENT) {
+               if (set)
+                       SET_FLAG(peer->af_flags[afi][safi],
+                                PEER_FLAG_NEXTHOP_UNCHANGED);
+               else
+                       UNSET_FLAG(peer->af_flags[afi][safi],
+                                  PEER_FLAG_NEXTHOP_UNCHANGED);
+       }
+
        /* Inherit from peer-group or set/unset flags accordingly. */
        if (peer_group_active(peer) && set == invert)
                peer_af_flag_inherit(peer, afi, safi, flag);