nexthop group extensions

bgpd/bgp_evpn_mh.c

@@ -2825,7 +2825,7 @@ static void bgp_evpn_l3nhg_zebra_add_v4_or_v6(struct bgp_evpn_es_vrf *es_vrf,
 			continue;
 
 		/* Don't overrun the zapi buffer. */
-		if (api_nhg.nexthop_num == MULTIPATH_NUM)
+		if (api_nhg.nhg_nexthop.nexthop_num == MULTIPATH_NUM)
 			break;
 
 		/* overwrite the gw */
@@ -2836,10 +2836,11 @@ static void bgp_evpn_l3nhg_zebra_add_v4_or_v6(struct bgp_evpn_es_vrf *es_vrf,
 						 es_vtep->vtep_ip);
 
 		/* convert to zapi format */
-		api_nh = &api_nhg.nexthops[api_nhg.nexthop_num];
+		api_nh = &api_nhg.nhg_nexthop
+				  .nexthops[api_nhg.nhg_nexthop.nexthop_num];
 		zapi_nexthop_from_nexthop(api_nh, &nh);
 
-		++api_nhg.nexthop_num;
+		++api_nhg.nhg_nexthop.nexthop_num;
 		if (BGP_DEBUG(evpn_mh, EVPN_MH_ES))
 			zlog_debug("nhg %u vtep %pI4 l3-svi %d", api_nhg.id,
 				   &es_vtep->vtep_ip,
@@ -2848,7 +2849,7 @@ static void bgp_evpn_l3nhg_zebra_add_v4_or_v6(struct bgp_evpn_es_vrf *es_vrf,
 		frrtrace(3, frr_bgp, evpn_mh_nh_zsend, nhg_id, es_vtep, es_vrf);
 	}
 
-	if (!api_nhg.nexthop_num)
+	if (!api_nhg.nhg_nexthop.nexthop_num)
 		return;
 
 	zclient_nhg_send(zclient, ZEBRA_NHG_ADD, &api_nhg);

bgpd/bgp_nhg.c

@@ -26,7 +26,7 @@ static void bgp_nhg_add_cb(const char *name)
 {
 }
 
-static void bgp_nhg_modify_cb(const struct nexthop_group_cmd *nhgc)
+static void bgp_nhg_modify_cb(const struct nexthop_group_cmd *nhgc, bool reset)
 {
 }
 
@@ -55,7 +55,7 @@ static void bgp_nhg_zebra_init(void)
 	bgp_nhg_start = zclient_get_nhg_start(ZEBRA_ROUTE_BGP);
 	nexthop_group_init(bgp_nhg_add_cb, bgp_nhg_modify_cb,
 			   bgp_nhg_add_nexthop_cb, bgp_nhg_del_nexthop_cb,
-			   bgp_nhg_del_cb);
+			   bgp_nhg_del_cb, NULL);
 }
 
 void bgp_nhg_init(void)

doc/user/nexthop_groups.rst

@@ -12,7 +12,7 @@ listing of ECMP nexthops used to forward packets.
    sub-mode where you can specify individual nexthops.  To exit this mode type
    exit or end as per normal conventions for leaving a sub-mode.
 
-.. clicmd:: nexthop [A.B.C.D|X:X::X:XX] [interface [onlink]] [nexthop-vrf NAME] [label LABELS]
+.. clicmd:: nexthop [A.B.C.D|X:X::X:XX] [interface [onlink]] [nexthop-vrf NAME] [label LABELS] [color (1-4294967295)]
 
    Create a v4 or v6 nexthop.  All normal rules for creating nexthops that you
    are used to are allowed here.  The syntax was intentionally kept the same as
@@ -27,3 +27,33 @@ listing of ECMP nexthops used to forward packets.
    will be automatically re-assigned.  This cli command must be the first
    command entered currently.  Additionally this command only works with linux 5.19
    kernels or newer.
+
+.. clicmd:: allow-recursion
+
+   Allow a next-hop to be resolved at zebra level. Instead of beig considered valid,
+   the next-hop is checked against route reachability at zebra level. This permits
+   sending an incomplete next-hop to zebra, whereas it was not authorised before.
+
+.. clicmd:: force-nexthop-config
+
+   Allow a Nexthop Group to be configured in ZEBRA, even if the nexthop has neither
+   an interface configured and no `allow-recursion` set.
+
+.. clicmd:: ibgp
+
+   Allow a Nexthop Group to be considered as an IBGP nexthop. When used in ZEBRA,
+   if `allow-recursion` is not used, some debug information is given.
+
+.. clicmd:: protocol-controlled
+
+   Allow a Nexthop Group to be completely controlled at the protocol level, by preventing
+   ZEBRA from creating a dependent NHG at ZEBRA Level. This option is useful when
+   protocol considers Nexthop Groups with multiple paths.
+
+.. clicmd:: group NAME
+
+   Append a Nexthop Group group dependency in the current nexthop group. When used with
+   the `protocol-controlled` option, the protocol daemon using it will ensure that the
+   dependent group is configured at the protocol level, and installed at ZEBRA level,
+   before installing the parent Nexthop Group. This option is very useful to consider
+   nexthop groups having multiple paths.