diff options
| author | Donald Sharp <sharpd@nvidia.com> | 2022-11-01 08:00:14 -0400 |
|---|---|---|
| committer | Donald Sharp <sharpd@nvidia.com> | 2022-11-04 12:02:00 -0400 |
| commit | a048d52399dfd99f0235b3f2e0766e2b98c62c8e (patch) | |
| tree | 1c59932a1ce1d97873978c85079338850f6298e5 /zebra/rt_netlink.c | |
| parent | 3e85fb337332c8dbdf0a8834515170556f530b94 (diff) | |
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>
Diffstat (limited to 'zebra/rt_netlink.c')
| -rw-r--r-- | zebra/rt_netlink.c | 3 |
1 files changed, 3 insertions, 0 deletions
diff --git a/zebra/rt_netlink.c b/zebra/rt_netlink.c index 3a8f5264f4..d02cc93f5f 100644 --- a/zebra/rt_netlink.c +++ b/zebra/rt_netlink.c @@ -803,6 +803,9 @@ static int netlink_route_change_read_unicast(struct nlmsghdr *h, ns_id_t ns_id, if (rtm->rtm_flags & RTM_F_OFFLOAD_FAILED) flags |= ZEBRA_FLAG_OFFLOAD_FAILED; + if (h->nlmsg_flags & NLM_F_APPEND) + flags |= ZEBRA_FLAG_OUTOFSYNC; + /* Route which inserted by Zebra. */ if (selfroute) { flags |= ZEBRA_FLAG_SELFROUTE; |