circuit deletion was being enforced by sending a fake IF_DOWN_FROM_Z
event for the circuit interface. This created a problem when the
circuit was enabled again, since isisd internal state machine was
expecting to see an IF_UP_FROM_Z that never came, as the interface
had not actually gone down.
As a consequence, disabling + re-enabling isis on an interface or
area would leave interfaces in a CONFIG state, and adjacencies were
not restored. Fix this by following the state machine and simply
disabling circuits rather than attempting to delete them forcefully.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
as part of the 'ip router isis TAG' command we were not validating
the MTU of the interface against the minimum LSP MTU of the area.
This could cause an assertion when the circuit is created in the
APPLY phase.
Fixes issue #4825
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
Make isisd create BFD sessions over IPv6 when IS-IS is configured
for IPv6 operation only.
When IS-IS is enabled for both IPv4 and IPv6 on a given interface,
prefer creating a BFD session over IPv6 to avoid having two BFD
sessions protecting the same IS-IS adjacency.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This unification allows us to write code that works for both IPv4 and
IPv6, reducing duplication.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
These null checks don't make sense because a) these two functions
are never called with a NULL IP address and b) the same pointers are
dereferenced later without any protection. Remove these NULL checks
to make the code less confusing.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
These fields were introduced by commit e38e0df01a, but they were
never put to any use. Remove them.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
We need to indent this command using one leading whitespace otherwise
vtysh will have problems to display it appropriately.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The correct cast for these is (unsigned char), because "char" could be
signed and thus have some negative value. isalpha & co. expect an int
arg that is positive, i.e. 0-255. So we need to cast to (unsigned char)
when calling any of these.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Introducing a 3rd state for route_map_apply library function: RMAP_NOOP
Traditionally route map MATCH rule apis were designed to return
a binary response, consisting of either RMAP_MATCH or RMAP_NOMATCH.
(Route-map SET rule apis return RMAP_OKAY or RMAP_ERROR).
Depending on this response, the following statemachine decided the
course of action:
State1:
If match cmd returns RMAP_MATCH then, keep existing behaviour.
If routemap type is PERMIT, execute set cmds or call cmds if applicable,
otherwise PERMIT!
Else If routemap type is DENY, we DENYMATCH right away
State2:
If match cmd returns RMAP_NOMATCH, continue on to next route-map. If there
are no other rules or if all the rules return RMAP_NOMATCH, return DENYMATCH
We require a 3rd state because of the following situation:
The issue - what if, the rule api needs to abort or ignore a rule?:
"match evpn vni xx" route-map filter can be applied to incoming routes
regardless of whether the tunnel type is vxlan or mpls.
This rule should be N/A for mpls based evpn route, but applicable to only
vxlan based evpn route.
Also, this rule should be applicable for routes with VNI label only, and
not for routes without labels. For example, type 3 and type 4 EVPN routes
do not have labels, so, this match cmd should let them through.
Today, the filter produces either a match or nomatch response regardless of
whether it is mpls/vxlan, resulting in either permitting or denying the
route.. So an mpls evpn route may get filtered out incorrectly.
Eg: "route-map RM1 permit 10 ; match evpn vni 20" or
"route-map RM2 deny 20 ; match vni 20"
With the introduction of the 3rd state, we can abort this rule check safely.
How? The rules api can now return RMAP_NOOP to indicate
that it encountered an invalid check, and needs to abort just that rule,
but continue with other rules.
As a result we have a 3rd state:
State3:
If match cmd returned RMAP_NOOP
Then, proceed to other route-map, otherwise if there are no more
rules or if all the rules return RMAP_NOOP, then, return RMAP_PERMITMATCH.
Signed-off-by: Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>
* Remove sanity checks that are already done by northbound;
* Show error message on circuit absence;
* Use a better idiom for the configuration display code;
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Specify the ISIS BFD command in the YANG model and implement the
northbound callbacks.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
The `isisd` will receive a northbound version of the BFD command, so
this is the first step to implement it.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
For some reason, the compiler on OpenBSD on our CI boxes doesn't like
struct initializers with ".a.b = x, .a.c = y", generating a warning
about overwritten initializers...
Signed-off-by: David Lamparter <equinox@diac24.net>
We need to be calling snprintfrr() instead of snprintf() in places that
wrap snprintf in some user-exposed way; otherwise the extensions won't
be available for those functions.
Signed-off-by: David Lamparter <equinox@diac24.net>
Field vrf_id is replaced by the pointer of the struct vrf *.
For that all other code referencing to (interface)->vrf_id is replaced.
This work should not change the behaviour.
It is just a continuation work toward having an interface API handling
vrf pointer only.
some new generic functions are created in vrf:
vrf_to_id, vrf_to_name,
a zebra function is also created:
zvrf_info_lookup
an ospf function is also created:
ospf_lookup_by_vrf
it is to be noted that now that interface has a vrf pointer, some more
optimisations could be thought through all the rest of the code. as
example, many structure store the vrf_id. those structures could get
the exact vrf structure if inherited from an interface vrf context.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
the vrf_id parameter is replaced by struct vrf * parameter.
this impacts most of the daemons that look for an interface based on the
name and the vrf identifier.
Also, it fixes 2 lookup calls in zebra and sharpd, where the vrf_id was
ignored until now.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The RFC states we can send only up to 16 v6 addresses in a hello packet
and cannot send sub tlv's of that type.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Introducing a 3rd state for route_map_apply library function: RMAP_NOOP
Traditionally route map MATCH rule apis were designed to return
a binary response, consisting of either RMAP_MATCH or RMAP_NOMATCH.
(Route-map SET rule apis return RMAP_OKAY or RMAP_ERROR).
Depending on this response, the following statemachine decided the
course of action:
Action: Apply route-map match and return the result (RMAP_MATCH/RMAP_NOMATCH)
State1: Receveived RMAP_MATCH
THEN: If Routemap type is PERMIT, execute other rules if applicable,
otherwise we PERMIT!
Else: If Routemap type is DENY, we DENYMATCH right away
State2: Received RMAP_NOMATCH, continue on to next route-map, otherwise,
return DENYMATCH by default if nothing matched.
With reference to PR 4078 (https://github.com/FRRouting/frr/pull/4078),
we require a 3rd state because of the following situation:
The issue - what if, the rule api needs to abort or ignore a rule?:
"match evpn vni xx" route-map filter can be applied to incoming routes
regardless of whether the tunnel type is vxlan or mpls.
This rule should be N/A for mpls based evpn route, but applicable to only
vxlan based evpn route.
Today, the filter produces either a match or nomatch response regardless of
whether it is mpls/vxlan, resulting in either permitting or denying the
route.. So an mpls evpn route may get filtered out incorrectly.
Eg: "route-map RM1 permit 10 ; match evpn vni 20" or
"route-map RM2 deny 20 ; match vni 20"
With the introduction of the 3rd state, we can abort this rule check safely.
How? The rules api can now return RMAP_NOOP (or another enum) to indicate
that it encountered an invalid check, and needs to abort just that rule,
but continue with other rules.
Question: Do we repurpose an existing enum RMAP_OKAY or RMAP_ERROR
as the 3rd state (or create a new enum like RMAP_NOOP)?
RMAP_OKAY and RMAP_ERROR are used to return the result of set cmd.
We chose to go with RMAP_NOOP (but open to ideas),
as a way to bypass the rmap filter
As a result we have a 3rd state:
State3: Received RMAP_NOOP
Then, proceed to other route-map, otherwise return RMAP_PERMITMATCH by default.
Signed-off-by:Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>
`strcpy` is a dangerous function and should not be used. In this
particular place, there is no need for copying strings at all, so let's
just stick to referencing static strings.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
There is no need to redefine `struct isis_lsp *lsp` inside of the
if condition. Let's just remove it.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
the buffer to read from the socket when processing an incoming
packet was hardcoded to be of size 8192. If the mtu of the
interface is greater than that and hello padding is enabled
on that circuit, the hello message will be truncated, and this
will cause the adjacency establishment to fail. fix this by
using a large enough stack buffer instead
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
This is necessary to avoid a name collision with std::for_each
from C++.
Fixes the compilation of the gRPC northbound module.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
It doesn't make much sense for a hash function to modify its argument,
so const the hash input.
BGP does it in a couple places, those cast away the const. Not great but
not any worse than it was.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
bfd cbit is a value carried out in bfd messages, that permit to keep or
not, the independence between control plane and dataplane. In other
words, while most of the cases plan to flush entries, when bfd goes
down, there are some cases where that bfd event should be ignored. this
is the case with non stop forwarding mechanisms where entries may be
kept. this is the case for BGP, when graceful restart capability is
used. If BFD event down happens, and bgp is in graceful restart mode, it
is wished to ignore the BFD event while waiting for the remote router to
restart.
The changes take into account the following:
- add a config flag across zebra layer so that daemon can set or not the
cbit capability.
- ability for daemons to read the remote bfd capability associated to a bfd
notification.
- in bfdd, according to the value, the cbit value is set
- in bfdd, the received value is retrived and stored in the bfd session
context.
- by default, the local cbit announced to remote is set to 1 while
preservation of the local path is not set.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
vrf_id parameter is added to the api of bfd_client_sendmsg().
this permits being registered to bfd from a separate vrf.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The Sub-TLVs of the Extended IPv4 reachability TLV were not being
displayed as expected. Fix this.
Suggested-by: Christian Franke chris@opensourcerouting.org
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This macro:
- Marks ZAPI callbacks for readability
- Standardizes argument names
- Makes it simple to add ZAPI arguments in the future
- Ensures proper types
- Looks better
- Shortens function declarations
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Historically, isisd has been carrying around its own red-black tree to
manage its LSP DB in. This replaces that with the newly-added
DECLARE_RBTREE_*. This allows completely removing the dict_* code.
Signed-off-by: David Lamparter <equinox@diac24.net>
The upcoming gRPC-based northbound plugin will run on a separate
pthread, and it will need to have access to the running configuration
global variable. Introduce a rw-lock to control concurrent access
to the running configuration. Add the lock inside the "nb_config"
structure so that it can be used to protect candidate configurations
as well (this might be necessary depending on the threading scheme
of future northbound plugins).
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
