Add a new field in the ZEBRA_CAPABILITIES zapi message specifying
the VRF backend in use.
For simplicity, make the zclient code call vrf_configure_backend()
to apply the received value automatically instead of requiring
the daemons to do that themselves in their zebra_capabilities()
callbacks.
Additionally, call zebra_vrf_update_all() only after sending the
capabilities message to the client, so that it will know which VRF
backend is in use when processing the VRF messages.
This commit fixes a couple of bugs in the "interface" CLI command and
associated northbound callbacks, which behave differently depending
on the VRF backend in use. Before this commit, the vrf_backend
variable would always be set to VRF_BACKEND_NETNS in the client
daemons, even when zebra was started without the --vrfwnetns option.
This could lead to inconsistent behavior and subtle bugs under
specific circumstances.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
{
struct zclient_capabilities cap;
struct stream *s = zclient->ibuf;
+ int vrf_backend;
uint8_t mpls_enabled;
+ STREAM_GETL(s, vrf_backend);
+ vrf_configure_backend(vrf_backend);
+
memset(&cap, 0, sizeof(cap));
STREAM_GETC(s, mpls_enabled);
cap.mpls_enabled = !!mpls_enabled;
struct stream *s = stream_new(ZEBRA_MAX_PACKET_SIZ);
zclient_create_header(s, ZEBRA_CAPABILITIES, zvrf->vrf->vrf_id);
+ stream_putl(s, vrf_get_backend());
stream_putc(s, mpls_enabled);
stream_putl(s, multipath_num);
}
zsend_capabilities(client, zvrf);
+ zebra_vrf_update_all(client);
stream_failure:
return;
}
frr_pthread_new(&zclient_pthr_attrs, "Zebra API client thread",
"zebra_apic");
- zebra_vrf_update_all(client);
-
/* start read loop */
zserv_client_event(client, ZSERV_CLIENT_READ);