interface link update event needs
to be handle properly in ospf interface
cache.
Example:
When vrf (interface) is created its default type
would be set to BROADCAST because ifp->status
is not set to VRF.
Subsequent link event sets ifp->status to vrf,
ospf interface update need to compare current type
to new default type which would be VRF (OSPF_IFTYPE_LOOPBACK).
Since ospf type param was created in first add event,
ifp vrf link event didn't update ospf type param which
leads to treat vrf as non loopback interface.
Ticket:#3459451
Testing Done:
Running config suppose to bypass rendering default
network broadcast for loopback/vrf types.
Before fix:
vrf vrf1
vni 4001
exit-vrf
!
interface vrf1
ip ospf network broadcast
exit
After fix: (interface vrf1 is not displayed).
vrf vrf1
vni 4001
exit-vrf
Signed-off-by: Chirag Shah <chirag@nvidia.com>
The tests are failing due to heavily loaded system and insufficient
time for large configs to be handled. Increasing the time
allows the tests to complete locally for me under heavy load.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
All paths of the loop set dest_addr at the start
of the loop. No need to set it to NULL to immediately
set it too something else.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Let's account for vpn_policy_getafi having a failure
situation and back out of the whole thing gracefully.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
It is impossible for the blnc statement to ever be NULL at
line 1470 as that the if statement at 1453 guarantees it
to be set to something.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The msg value is always reset to something new before it is used inside
the mutex. No need to set it to NULL.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
A configured flex-algo algorithm may remain in disabled state after its
definition is advertised on the area.
It happens sometimes that, in isis_sr_flex_algo_topo1 topotest step 4 or
8, flex-algo 203 is disabled. It depends on the following sequence:
1. Flex-algo 203 is configured on a remote router to be re-advertised.
2. A LSP is received on the local router and contains the algo 203
definition.
3. The local router re-builds its own LSP with lsp_build().
4. local router isis_run_spf() recomputes the algo 203 SPF tree.
A 1. 2. 3. 4. sequence results in a working test. The reception of the
remote LSP (2.) does not trigger the built of the local LSP. If for
some reasons, the sequence is 1. 3. 4. 2. 4., isis_run_spf() will not
knows that flex-algo 203 has been re-enabled because
flex_algo_get_state() only returns the state from the local LSP.
Compare in sequence step 4. the flex-algo state from the local LSP with
the actual state. If the state is not the same, request a new local LSP
generation and quits the re-computation of algo SPF tree. The SPF tree
will be recomputed just after the built of the local LSP.
Fixes: 3f55b8c621 ("isisd: fix disabled flex-algo on race condition")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Some test steps result in removing some entries in the MPLS forwarding
table. However, these steps pass before the entries are actually
removed.
Use the exact JSON comparison so that the removal of the entries is
checked.
Fixes: 1a61ef95b2 ("tests: add isis_sr_flex_algo_topo1 for flex-algo")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
When using a context to send route notifications to upper
level protocols, the code was using a locking function to
get the route node. There is no need for this to be locked
as such FRR should free it up.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Commit 76249532fa ("ospf6d: Handle Premature Aging of LSAs") added a
duplicate call to OSPF6_INTRA_PREFIX_LSA_EXECUTE_TRANSIT(), when the
interface state changes to "Down".
Fixes: #1738
Signed-off-by: David Ward <david.ward@ll.mit.edu>
When issue vtysh command with ?, the initial buf size for the
element is 16. Then it would loop through each element in the cmd
output vector. If the required size for printing out the next
element is larger than the current buf size, realloc the buf memory
by doubling the current buf size regardless of the actual size
that's needed. This would cause vtysh core when the doubled size
is not enough for the next element.
Signed-off-by: Yuan Yuan <yyuanam@amazon.com>
Keep only 3 release dates, current and two upcoming. On the next release,
just update one, instead of multiple (zero point looking too much in the
future).
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Not sure why it's here, but looks like it was since the beginning, let's see
if we can drop it.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
There is no way that xpath can ever be anything but NULL
in the failure path with the goto's. Let's just remove
the goto's and return immediately.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When the remote peer is neither EBGP nor confed, aspath is the
shadow copy of attr->aspath in bgp_packet_attribute(). Striping
AS4_PATH should not be done on the aspath directly, since
that would lead to bgpd core dump when unintern the attr.
Signed-off-by: Yuan Yuan <yyuanam@amazon.com>
Change timestamp parameter from int to time_t to avoid truncation.
Found by Coverity Scan (CID 1563226 and 1563222)
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The rn variable has its info attribute being replaced with a new ospf route before being freed properly.
Signed-off-by: ryndia <dindyalsarvesh@gmail.com>
In CI, CLANG static analyzer started complaining about possible null
dereferences of pre-existing fields. Let's make it happy and do a null
check.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
Change CMD_WARNING -> CMD_WARNING_CONFIG_FAILED so that the rc is
non-zero and the caller can detect a failure.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
Adds a generalized martian reimport function used for triggering a
relearn/reimport of EVPN routes that were previously filtered/deleted
as a result of a "self" check (either during import or by a martian
change handler). The MAC-VRF SoO is the first consumer of this function,
but can be expanded for use with Martian Tunnel-IPs, Interface-IPs,
Interface-MACs, and RMACs.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
Currently we have a handler function that will walk the global EVPN
rib and unimport/remove routes matching a local IP/TIP. This generalizes
this function so that it can be re-used for other BGP Martian entry
types. Now this can be used to unimport routes when the MAC-VRF SoO is
reconfigured.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
For whatever reason, we were only updating tip_hash when we processed an
L2VNI add/del. This adds tip_hash updates to the L3VNI add/del codepaths
so that their VTEP-IPs are also used when when considering martian
addresses, e.g. bgp_nexthop_self().
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
All uses of struct bgp_addrv6 were removed in a prior commit that made
struct bgp_addr reusable for both v4 and v6. This cleans up the last
remnants of the old v6 struct.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
Initial support for configuring an SoO for all MAC-VRFs (EVIs/L2VNIs).
This provides a topology-independent method of preventing EVPN routes
from one MAC-VRF "site" (an L2 domain) from being imported by other PEs
in the same MAC-VRF "site", similar to how SoO is traditionally used in
L3VPN to identify and break loops for an L3/IP-VRF "site".
One example of where a MAC-VRF SoO can be used to avoid an L2 control
plane loop is with Active/Active MLAG VTEPs. For a given L2 site only
one control plane should be active. SoO can be used to ID/ignore entries
originated from the local MAC-VRF site so that EVPN will not attempt to
manage entries that are already handled by MLAG.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
bgp_create() and bgp_free() already call EVPN-specific handlers,
so there's no need to XCALLOC/XFREE BGP_EVPN_INFO directly. Let's move
all the references to MTYPE_BGP_EVPN_INFO into the EVPN specific files.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
When processing an interface up/create event from zebra, we insert that
interface's MAC address into the self_mac_hash used for dropping EVPN
routes carrying a 'self mac' (RMAC ext-comm or MAC in Type-2 NLRI).
However, we were unconditionally triggering a "rescan" of the EVPN RIB
to ensure we handle routes that match the MAC - even if the MAC already
existed in self_mac_hash (i.e. the change wasn't actionable).
This adds logic to only kick off a "rescan" if the MAC learned from
zebra is not already in the self_mac_hash.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
