lib, zebra: Allow for zebra to recognize that a route has gotten desynced

FRR does not use the NLM_F_APPEND semantics ( in fact I would argue that
the NLM_F_APPEND semantics just introduce pain for all parties involved )
I would also argue that most people who use the kernel netlink api
have recognized that NLM_F_APPEND for a route is a recipe for disaster
that is well documented and as such it is not used as anything other
than a curiousity by operators.

See:
https://bugzilla.redhat.com/show_bug.cgi?id=1337855
https://github.com/thom311/libnl/issues/226

Are 2 great examples of how confusing it is for anyone in user
space to know what the correct thing to do is.  Given that
new fields can be added with no semantics to allow us to know
what has resulted in a change or not.

In an attempt to recognize this, let's note that FRR
believes it has gotten out of sync with the kernel.
Future commits will react to the desynchronized route
and request from the kernel a reload of that specific
route if possible.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>

1 files changed, 7 insertions, 0 deletions

diff --git a/lib/zclient.h b/lib/zclient.h
index fb5da9aad..e6920d533 100644
--- a/lib/zclient.h
+++ b/lib/zclient.h
@@ -540,6 +540,13 @@ struct zapi_route {
  */
 #define ZEBRA_FLAG_OFFLOAD_FAILED     0x200
 
+/*
+ * This flag lets us know that we think the route entry
+ * received has caused us to be out of sync with the
+ * kernel (NLM_F_APPEND at the very least )
+ */
+#define ZEBRA_FLAG_OUTOFSYNC          0x400
+
 	/* The older XXX_MESSAGE flags live here */
 	uint32_t message;