From: Donald Sharp <sharpd@cumulusnetworks.com>
Date: Sat, 28 Mar 2020 17:58:46 +0000 (-0400)
Subject: bgpd: When acting as a RR server do not modify nexthop
X-Git-Tag: base_7.4~160^2~1
X-Git-Url: https://git.puffer.fish/?a=commitdiff_plain;h=99819027b1b3e969fed75253aef24c480000fab1;p=mirror%2Ffrr.git

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 9452770100..6534ac1900 100644
--- 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);