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 742ef217d97b224ec60d60421bbcc2b038ad3e17..6f7424c5eadca1d5c53a911f0ecd67908e183c93 100644 (file)
--- 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;
                }