Note that we do not return the actual tlv_type and offset
of the erroneous TLV. This is because unpacking tlvs currently
uses a chain of function calls, where the notification can only
be sent at the start of the chain, but the tlv_type and offset
information are only available at the end. Unless we change the
code to propagate those values, we have no way to feed them to
the notification. So these leafs are not generated.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
isisd: implement the authentication failure notifications
the original isisd code did not distinguish between
authentication_failure and authentication_type_failure, so
additional code had to be added to differentiate between the two
and to return the raw_pdu as requested by the IETF YANG model.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
Note that the original IETF YANG model also included
a requirement to throttle such notifications so that they would
not be sent more often than once every 5 seconds. I did not
implement any throttling mechanism yet, mostly because I am
not sure whether this limit should apply to the entire isis daemon,
to each area, to each neighbor etc.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
This is a simple command but with a complex callback, the only
one in isisd which uses the resource allocation API implemented
in the northbound (i.e. the PREPARE phase).
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
isisd: retrofit 'router isis' and 'ip router isis' cmds
These are complex commands to retrofit, partly due to the number of
different callbacks they touch. Additionally, in FRR adding
an interface to an IS-IS area that does not exist also creates that
area. To make sure that this behavior is kept, while at the same
time keeping the northbound api consistent, we need to take extra
care to call the appropriate callbacks to update the YANG tree.
Note that many callbacks rely on the existence of the corresponding
IS-IS area; when these callbacks are joined together in a single
transaction, we need to ensure that the area creation is performed
first, or the config will fail. For this reason, the isis instance
create callback has been given a slightly lower priority than the
others.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
Just copying th const char* of the xpath means that if we
are enqueing multiple changes from a buffer, the last xpath
addedd will overwrite all of the previous references.
Copying the xpath to a buffer simplifies the API when
retrofitting the commands.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
As suggested by Renato, add error codes that are specific
to the various phases of a northbound callback. These can
be used by the daemons when logging an error. The reasoning
is that validation errors typically mean that there is an
inconsistency in the configuration, a prepare error means
that we are running out of resources, and abort/apply errors
are bugs that need to be reported to the devs.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
zebra: avoid initialising more than one the l3vni hash structure
the l3vni structure is allocated only once, since that structure is only
used for default netns. For that, move the initialisation part is moved
to a proper place, where there is no risk of attempting to initialise it
more than once, even when vrf backend is netns.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Donald Sharp [Sat, 15 Dec 2018 15:49:59 +0000 (10:49 -0500)]
topotests: Cleanup diagnose_env to allow thought about multi-platforms
Start the cleanup of diagnose_env to allow the running of topotests
on platforms besides linux.
So we split up diagnose_env into linux and freebsd variants.
At this point in time freebsd doesn't have any special code.
To be determined in the future.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Mark Stapp [Thu, 13 Dec 2018 19:15:27 +0000 (14:15 -0500)]
zebra: use a small retry timeout for the rib workqueue
In the zebra rib processing workqueue, set a small timeout
so that we will wait a short time if the queue into the
async dataplane is full. This helps avoid a situation where
the zebra main pthread constantly retries rib work without
giving the dataplane pthread a chance to make progress.
Mark Stapp [Tue, 11 Dec 2018 19:56:08 +0000 (14:56 -0500)]
libs: support timeout for workqueue retries
Support an optional timeout/delay for use when a workqueue
determines that it is blocked, instead of retrying immediately.
Also, schedule as an 'event' instead of a 'timer' when using
a zero timeout value.
Donald Sharp [Thu, 13 Dec 2018 14:21:26 +0000 (09:21 -0500)]
zebra: Allow zebra to only mark up to multipath_num nexthops as ACTIVE
NEXTHOP_FLAG_ACTIVE currently means that the nexthop is considered
good enough to be installed. With current ecmp restrictions this
translation from multipath_num is enforced in the data plane.
The problem with this is of course that every data plane now
becomes concerned about the multipath num and must enforce it
independently. Currently *bsd does not honor multipath_num at
all and linux marks all nexthops as being installed even when
it honors a multipath_num that is less than the total.
This code change moves the multipath_num enforcement from a dataplane
decision to a zebra nexthop decision. Thus dataplanes now can
just install those nexthops marked as NEXTHOP_FLAG_ACTIVE
without having to worry about multipath_num.
*BSD will now respect multipath_num and Linux now properly notes
which routes are actually installed or not:
donna.cumulusnetworks.com(config)# do show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR, f - OpenFabric,
> - selected route, * - FIB route
K>* 0.0.0.0/0 [0/106] via 10.0.2.2, enp0s3, 00:00:45
S>* 4.4.4.4/32 [1/0] via 10.0.2.1, enp0s3, 00:00:02
* via 192.168.209.1, enp0s8, 00:00:02
via 192.168.210.1, enp0s9 inactive, 00:00:02
C>* 10.0.2.0/24 is directly connected, enp0s3, 00:00:45
C>* 192.168.209.0/24 is directly connected, enp0s8, 00:00:45
C>* 192.168.210.0/24 is directly connected, enp0s9, 00:00:45
donna.cumulusnetworks.com(config)#
sharpd@donna ~/f/t/topotests> ip route show
default via 10.0.2.2 dev enp0s3 proto dhcp metric 106
4.4.4.4 proto 196 metric 20
nexthop via 10.0.2.1 dev enp0s3 weight 1
nexthop via 192.168.209.1 dev enp0s8 weight 1
10.0.2.0/24 dev enp0s3 proto kernel scope link src 10.0.2.15 metric 106
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
192.168.209.0/24 dev enp0s8 proto kernel scope link src 192.168.209.2 metric 105
192.168.210.0/24 dev enp0s9 proto kernel scope link src 192.168.210.2 metric 103 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Mark Stapp [Tue, 11 Dec 2018 19:17:42 +0000 (14:17 -0500)]
zebra: make incoming zserv message-processing a singleton event
Stop creating individual, one-time events as each batch of
incoming zserv/zapi messages is processed - use a singleton
event so that the incoming message activity is more fair if
the zebra main pthread has other events to run.
projects / mirror / frr.git / log