Zebra neigh update #15179
Zebra neigh update #15179
Conversation
donaldsharp
force-pushed
the
zebra_neigh_update
branch
from
75a84c4 to
36a2e7d
Compare
This does not need to be nhrp specific. Signed-off-by: Donald Sharp <[email protected]>
This is needed to be generic. Let's make it so. Signed-off-by: Donald Sharp <[email protected]>
Signed-off-by: Donald Sharp <[email protected]>
donaldsharp
force-pushed
the
zebra_neigh_update
branch
from
36a2e7d to
01cb1fb
Compare
| @@ -154,6 +154,10 @@ int nhrp_neighbor_operation(ZAPI_CALLBACK_ARGS) | |||
| struct zapi_neigh_ip api = {}; | |||
|
|
|||
| zclient_neigh_ip_decode(zclient->ibuf, &api); | |||
|
|
|||
There was a problem hiding this comment.
Perhaps a comment on why you are allowing only /32 is welcome.
There was a problem hiding this comment.
lol. That is what the original code did. I just moved it from Zebra to up into nhrpd. I don't fully understand it but if I had to guess it's a RTM_NEIGH entry where the lladr is set to a v4 address. I left it alone mainly because I didn't know and didn't want to take the time to figure it out.
| in, out, ifp, | ||
| out ? ZEBRA_NEIGH_STATE_REACHABLE | ||
| : ZEBRA_NEIGH_STATE_FAILED, | ||
| 0); |
There was a problem hiding this comment.
please add comment of the meaning of 0 (hardcoded value)
something like
0); // meaning something cool
This is the ip_len. Why are you using 0?
| @@ -27,6 +27,32 @@ | |||
|
|
|||
| DEFINE_MTYPE_STATIC(SHARPD, SRV6_LOCATOR, "SRv6 Locator"); | |||
|
|
|||
| DEFPY(watch_neighbor, watch_neighbor_cmd, | |||
There was a problem hiding this comment.
This was a Proof of Concept bit of code. I don't mind having it and I don't mind not having it. An end operator is not likely to ever use this.
| @@ -989,6 +989,41 @@ static int sharp_zebra_process_srv6_locator_chunk(ZAPI_CALLBACK_ARGS) | |||
| return 0; | |||
| } | |||
|
|
|||
| static int sharp_zebra_process_neigh(ZAPI_CALLBACK_ARGS) | |||
There was a problem hiding this comment.
This function always return 0.
What is the difference between failure and success?
There was a problem hiding this comment.
This is a bit of a historical baggage that is carried around at the moment, that needs to be cleaned up. The original code all had this idea of returning error messages. But whenever a non-zero was returned it was always ignored. When the current handler code was abstracted, by Quentin, to use arrays of function pointers it got carried over. The original coder of a lot of functionality in FRR had this idea of returning 0 or 1 for success and immediately throwing the answer away and never using it. We've cleaned up large swaths. This is just another example of something that needs to be fixed from my perspective.
a) Abstract neighbor events away from nhrp specific.
b) Add a
sharp watch neighborcommand so that neighbor events can be monitored.Effectively future commits will have other daemons watching more neighbor events.