zapi_nbr structure is renamed to zapi_neigh_ip.
Initially used to set a neighbor ip entry for gre interfaces, this
structure is used to get events from the zebra layer to nhrp layer.
The ndm state has been added, as it is needed on both sides.
The zebra dplane layer is slightly modified.
Also, to clarify what ZEBRA_NEIGH_ADD/DEL means, a rename is done:
it is called now ZEBRA_NEIGH_IP_ADD/DEL, and it signified that this
zapi interface permits to set link operations by associating ip
addresses to link addresses.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
a zebra api is extended to offer ability to add or remove neighbor
entry from daemon. Also this extension makes possible to add neigh
entry, not only between IPs and macs, but also between IPs and NBMA IPs.
This API supports configuring ipv6/ipv4 entries with ipv4/ipv6 lladdr.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
neighbor notifications are done in zebra. so, instead of relying on
nhrp, rely on zebra by using zebra api interface.
Consequently, the code originally used in nhrp for netlink neighor
notification is no more used.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
lookup appropriate ipsec path. there are systems where the path where
the charon.vici file is not in standard paths. For that, 'ipsec
--piddir' may help in solving the path.
result of ipsec --piddir is as follow for example:
'
/etc/ike/ipsec.d/run
'
Note that the assumption is done that even if there are several
instances of strongswan across the vrfs, the charon.vici path file is
the same across vrfs. Consequently, as there is a thread per vrf that
performs vici initialisation, and file path retrieval is part of the
vici initialisation procedure, in order to avoid intempestive system
calls, use a boolean 'vici_charon_filepath_done' to avoid doing
unnecessary calls.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
For some reason the usage of tabs in a string snuck in as well
as using a sockunion2str instead of %pSU. Fix.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Back when I put this together in 2015, ISO C11 was still reasonably new
and we couldn't require it just yet. Without ISO C11, there is no
"good" way (only bad hacks) to require a semicolon after a macro that
ends with a function definition. And if you added one anyway, you'd get
"spurious semicolon" warnings on some compilers...
With C11, `_Static_assert()` at the end of a macro will make it so that
the semicolon is properly required, consumed, and not warned about.
Consistently requiring semicolons after "file-level" macros matches
Linux kernel coding style and helps some editors against mis-syntax'ing
these macros.
Signed-off-by: David Lamparter <equinox@diac24.net>
This prevents a failed IPSec connection from preventing DMVPN from working.
A failure situation can be reproduced using a Cisco peer, and and disabling then
re-enabling the tunnel IPSec protection (after the IPSec connection has
already been established).
Signed-off-by: Reuben Dowle <reuben.dowle@4rf.com>
If hop count is 0, this causes Cisco routers to reject the traffic indication
as invalid. This appears to be a Cisco bug, and has been observed in processing
of registration packets in the past. That problem was covered in issue #951
Signed-off-by: Reuben Dowle <reuben.dowle@4rf.com>
Clang was complaining when running SA that the nhrpd_privs.change
function was null. It just does not fully understand how things
are setup. Add a assert to make it happy.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
There are cases where nhrp wants to create a nhrp route to gre interface
with the nexthop which is the same the prefix. This is the case with
ipv6:
ipv6 route a:ff::ff:4/128 via a:ff::ff:4:/128 dev gre1
This route entry is false from zebra point of view, and to avoid that,
the nexthop is ignored in nhrp only if the prefix equals the nexthop.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Previously, when a shortcut entry was created, its associated route was
created on system, with no nexthop, only gre device. eg:
[..]
N>* 192.168.2.0/24 [10/0] is directly connected, gre1, 00:01:04 <--- can not be resolved
[..]
Type Prefix Via Identity
dynamic 192.168.2.0/24 10.255.255.2 <---- correct
This situation was forcing neighbor resolution on the first outgoing packet matching the route entry. for instance 192.168.2.1 could not be resolved at link layer, and was going to fail. Instead, nhrp nexthop should have been used.
This is what this commit intends to do, that is to say that when a
shortcut is installed by nhrp, the associated nexthop entry is used.
[..]
N>* 192.168.2.0/24 [10/0] via 10.255.255.2, gre1 onlink, 00:00:31
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
