From: Philippe Guibert <philippe.guibert@6wind.com>
Date: Wed, 30 Jun 2021 12:07:52 +0000 (+0200)
Subject: bgpd: nht unresolved with global address next-hop
X-Git-Tag: base_8.1~352^2
X-Git-Url: https://git.puffer.fish/?a=commitdiff_plain;h=17ef5a934355a718caf64f2fd5cac5e252977890;p=mirror%2Ffrr.git

bgpd: nht unresolved with global address next-hop

When bgp peers with ipv6 link local addresses, it may receive a
BGP update with next-hop containing both LL and GA information.
By default, nexthop tracking applies to GA, and ignores presence
of LL, when both addresses are present. This is a problem for
resolving GA as next-hop as the next-hop information can be solved
by using the LL address only.

The solution consists in defaulting the nexthop ipv6 choice to LL
when available, and moving back to GA if a route-map is locally
configured at inbound.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
---

diff --git a/bgpd/bgp_nht.c b/bgpd/bgp_nht.c
index 742ef217d9..6f7424c5ea 100644
--- a/bgpd/bgp_nht.c
+++ b/bgpd/bgp_nht.c
@@ -793,7 +793,18 @@ static int make_prefix(int afi, struct bgp_path_info *pi, struct prefix *p)
 				|| IN6_IS_ADDR_LINKLOCAL(
 					&pi->attr->mp_nexthop_global)))
 				p->u.prefix6 = pi->attr->mp_nexthop_local;
-			else
+			/* If we receive MR_REACH with (GA)::(LL)
+			 * then check for route-map to choose GA or LL
+			 */
+			else if (pi->attr->mp_nexthop_len
+				 == BGP_ATTR_NHLEN_IPV6_GLOBAL_AND_LL) {
+				if (pi->attr->mp_nexthop_prefer_global)
+					p->u.prefix6 =
+						pi->attr->mp_nexthop_global;
+				else
+					p->u.prefix6 =
+						pi->attr->mp_nexthop_local;
+			} else
 				p->u.prefix6 = pi->attr->mp_nexthop_global;
 			p->prefixlen = IPV6_MAX_BITLEN;
 		}