Use the zapi client session id in the label manager apis;
use the client struct directly in some code. Assign a session
id to ldpd's sync LM zapi session.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
And again for the name. Why on earth would we centralize this, just so
people can forget to update it?
Signed-off-by: David Lamparter <equinox@diac24.net>
Same as before, instead of shoving this into a big central list we can
just put the parent node in cmd_node.
Signed-off-by: David Lamparter <equinox@diac24.net>
There is really no reason to not put this in the cmd_node.
And while we're add it, rename from pointless ".func" to ".config_write".
[v2: fix forgotten ldpd config_write]
Signed-off-by: David Lamparter <equinox@diac24.net>
The only nodes that have this as 0 don't have a "->func" anyway, so the
entire thing is really just pointless.
Signed-off-by: David Lamparter <equinox@diac24.net>
Per issue #6202
Very long passwords (>79 chars) get truncated: save truncated
length in nbrp->auth.md5key_len instead of original length.
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
When the Independent Control mode is in use (the default one),
each LDP speaker allocates labels independently, which can lead to
broken LSPs when the LDP and IGP domains are not congruent.
What we were doing in this case was to drop all packets coming
through a broken LSP, which causes drastic side effects in the
network like loss of IP connectivity between routers.
We can however do a best-effort attempt to avoid packet loss by
popping the top-level label of the incoming packets and forwarding
them normally to their nexthops. This will be enough to guarantee
that labeled IP packets will reach their final destination. The
broken LSPs will still be unsuitable to tunnel labeled traffic, like
VPN packets, but in this case there's nothing we can do about it.
Cisco's IOS does something similar, called the "Untagged/No Label"
operation, which removes the entire label stack and forward the
packet unlabeled. We don't have such functionality available in the
Linux kernel, but this shouldn't make any difference for practical
purposes.
Fixes#6127.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
There is configuration in LDP to only create labels for
host-routes. If the user remove this configuration the code
was not readvertising non-host routes to it's LDP neighbors.
The issue is the same in reverse also. If the user adds this
configuration on an active LDP session the non-host routes were
not withdrawn.
Signed-off-by: Lynne Morrison <lynne@voltanet.io>
This is a full rewrite of the "back end" logging code. It now uses a
lock-free list to iterate over logging targets, and the targets
themselves are as lock-free as possible. (syslog() may have a hidden
internal mutex in the C library; the file/fd targets use a single
write() call which should ensure atomicity kernel-side.)
Note that some functionality is lost in this patch:
- Solaris printstack() backtraces are ditched (unlikely to come back)
- the `log-filter` machinery is gone (re-added in followup commit)
- `terminal monitor` is temporarily stubbed out. The old code had a
race condition with VTYs going away. It'll likely come back rewritten
and with vtysh support.
- The `zebra_ext_log` hook is gone. Instead, it's now much easier to
add a "proper" logging target.
v2: TLS buffer to get some actual performance
Signed-off-by: David Lamparter <equinox@diac24.net>
Zebra is currently sending messages on interface add/delete/update,
VRF add/delete, and interface address change - regardless of whether
its clients had requested them. This is problematic for lde and isis,
which only listens to label chunk messages, and only when it is
waiting for one (synchronous client). The effect is the that messages
accumulate on the lde synchronous message queue.
With this change:
- Zebra does not send unsolicited messages to synchronous clients.
- Synchronous clients send a ZEBRA_HELLO to zebra.
The ZEBRA_HELLO contains a new boolean field: sychronous.
- LDP and PIM have been updated to send a ZEBRA_HELLO for their
synchronous clients.
Signed-off-by: Karen Schoener <karen@voltanet.io>
LDP ordered label distribution control only binds a label to
a FEC if it is the egress LSR, or the router received a label
binding for a FEC from the next hop router. In this mode,
an MPLS router will create a label binding for each FEC and
distribute it to its neighbors so long as he has a entry in
the RIB for the destination.
Signed-off-by: Lynne Morrison <lynne@voltanet.io>
Signed-off-by: Karen Schoener <karen@voltanet.io>
As I understand it ldpd was originally developed as a standalone
daemon for *BSD land. Then ported to FRR. FRR uses ifindex_t
as the base type for the ifindex. Mixing `unsigned short` and
`int` and `unsigned int` is going to lead to fun somewhere
along the way. Especially when we get to run on a system
with ifindex churn( I'm looking at you docker ).
Attempt to convert all of ldpd to think of the ifindex as a
`ifindex_t`.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
GCC 10 switched to -fno-common by default, see
https://gcc.gnu.org/gcc-10/porting_to.html#common for details.
Fixes:
CCLD ldpd/ldpd
/usr/bin/ld: ldpd/libldp.a(adjacency.o):/home/ruben/src/frr/ldpd/ldpe.h:294: multiple definition of `pkt_ptr'; ldpd/ldpd.o:/home/ruben/src/frr/ldpd/ldpe.h:294: first defined here
Signed-off-by: Ruben Kerkhof <ruben@rubenkerkhof.com>
The lif variable was being set in the if statement and
immediately copied into from xf. No need to do this
twice.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Use the zapi_nexthop struct with the mpls_labels
zapi messages instead of the special-purpose (and
more limited) nexthop struct that was being used.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
The vrrpd one conflicts with the standalone vrrpd package; also we're
installing daemons to /usr/lib/frr on some systems so they're not on
PATH.
Signed-off-by: David Lamparter <equinox@diac24.net>
Validate that the FEC prefix length is within the allowed limit
(depending on the FEC address family) in order to prevent possible
buffer overflows.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
For all the places we have a zclient->interface_up convert
them to use the interface ifp_up callback instead.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Switch the zclient->interface_add functionality to have everyone
use the interface create callback in lib/if.c
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Start the conversion to allow zapi interface callbacks to be
controlled like vrf creation/destruction/change callbacks.
This will allow us to consolidate control into the interface.c
instead of having each daemon read the stream and react accordingly.
This will hopefully reduce a bunch of cut-n-paste stuff
Create 4 new callback functions that will be controlled by
lib/if.c
create -> A upper level protocol receives an interface creation event
The ifp is brand spanking newly created in the system.
up -> A upper level protocol receives a interface up event
This means the interface is up and ready to go.
down -> A upper level protocol receives a interface down
destroy -> A upper level protocol receives a destroy event
This means to delete the pointers associated with it.
At this point this is just boilerplate setup for future commits.
There is no new functionality.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This new message makes it possible to install/reinstall LSPs with
multiple nexthops using a single ZAPI message.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
* Add ability to specify the nexthop type;
* Add ability to install or not a FTN (in addition to an LSP).
These two additions will be useful to install local SR Prefix-SIDs
configured with the no-PHP option.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Use the route type and instance instead of the route distance
to identify MPLS FTNs. This is a more robust approach since the
routing daemons can modify the distance of their announced routes
via configuration, which can cause inconsistencies.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Do this for the following reasons:
* Improve modularity of the code by separating the decoding of the
ZAPI messages from their processing;
* Create an API that is easier to use by the client daemons.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
LDP opens two sockets to zebra, one through ldpd (always using
instance 0) and another through lde (using whatever instance
was set through the -n command line parameter). If no instance
was set, both connections would use the same protocol and instance,
making it impossible to distinguish them through zserv_find_client.
This meant that a response to a lm connect would erroneously go to
the wrong process. Fix this by having a default instance value of 1,
in case the user does not specify a different one.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
For SRGB, we need to support chunk requests starting at a
specific point in the label space, rather than just asking
for any sufficiently large chunk. To this purpose, we extend
the label manager api to request a chunk with a base value;
if the base is set to 0, the label manager will behave as it
currently does, i.e. fetching the first free chunk big enough
to satisfy the request.
update all the existing calls to get chunks from the label
manager so that they use MPLS_LABEL_BASE_ANY as the base
for the requested chunk
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
