Instead of trying to maintain if_ospf_cli_count, let's directly count
the number of configured interfaces when it is needed. Current approach
sometimes leads to an incorrect counter.
Fixes#8321.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Description:
OSPF does not have an option to control the maximum multiple
equal cost paths to reach a destination/route(ECMP).
Currently, it is using the system specific max multiple paths.
But Somtimes, It requires to control the multiple paths from ospf.
This cli helps to configure the max number multiple paths in ospf.
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
The checks were incorrectly removed in commit 4d2f546f under the
assumption that it is needed only in CLI. Actually the checks are needed
for the case when the sequence number is explicitly set by a user.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
There was an attempt to consolidate the code in commit fae60215, but the
work was not actually finished and some necessary checks were missed.
Let's finish it.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Three new tests:
- OSPFv3 convergence using 'ipv6 ospf6 neighbor json'
- Default route functionality:
* Check that the LSA is present
* Check that the route was installed
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
During Review it was suggested that appending rpki_
to curr_state and target_state would be better
variable names. Instead of going and fixing
3 or so commits up. Just do this one.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Add the ability for the end operator to query the state of valid
or invalid or no information rpki prefix information.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When displaying data about the rpki state, use the
string `rpki validation-state` instead of `validation-state:`
to avoid confusion with `(valid)`
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The MH datastructures were being released before the paths that were
referencing them. Fix is to do the MH cleanup last.
The MH finish function has also been stripped down to only do a
datastructure cleanup i.e. avoid sending route updates etc.
Ticket: 31376
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
1. When a local ES is deleted or the ES-bond goes into bypass we treat
imported MAC-IP routes with that ES destination as remote routes instead
of sync routes. This requires a re-evaluation of the routes as
"non-local-dest" and an update to zebra.
2. When a ES is attached to an access port or the ES-bond transitions from
bypass to LACP-up we treat imported MAC-IP routes with that ES destination as
sync routes. This requires a re-evaluation of the routes as
"local-dest" and an update to zebra.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
In the case of EVPN type-2 routes that use ES as destination, BGP
consolidates the nh (and nh->rmac mapping) and sends it to zebra as
a nexthop add.
This nexthop is the EVPN remote PE and is created by reference of
VRF IPvx unicast paths imported from EVPN Type-2 routes.
zebra uses this nexthop for setting up a remote neigh enty for the PE
and a remote fdb entry for the PE's RMAC.
Ticket: CM-31398
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Setup a mh_info indirection in the path extra. This has been done to
avoid increasing evpn route's path size to add new (type based) pointers
in path_info_extra.
Ticket: CM-31398
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
EVPN nexthops are installed as remote neighs by zebra. This was earlier
done only via VRF IPvX uni routes imported from EVPN routes.
With EVPN-MH these VRF routes now reference a L3NHG which is setup based
on the EAD and doesn't include the RMAC. To workaround that BGP now
consolidates and maintains EVPN nexthops which are then sent to zebra.
zebra sets up these nexthops as L3-VNI nh entries using a dummy type-1
route as reference.
Ticket: CM-31398
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Theoretically we should just be able to use the L3 NHG in the other-VRF/nh-VRF.
But there is some change list handling (when an ES is added to or
removed from a VRF) that needs to be updated to account for routes in other
VRFs using that ES-VRF as nexthop. Till that is done we will disable L3-NHG
use for routes leaked from a different VRF.
Route in tenant2 with ES/NHG as destination -
===========================================
root@leaf11:mgmt:~# ip route show vrf tenant2 22.1.0.7
22.1.0.7 nhid 75000012 proto bgp metric 20
root@leaf11:mgmt:~# ip nexthop list id 75000012
id 75000012 group 103/107/111 proto bgp
root@leaf11:mgmt:~# ip nexthop |grep "103\|107\|111"
id 103 via 6.0.0.11 dev vlan12 scope link proto bgp onlink
id 107 via 6.0.0.12 dev vlan12 scope link proto bgp onlink
id 111 via 6.0.0.13 dev vlan12 scope link proto bgp onlink
id 75000012 group 103/107/111 proto bgp
root@leaf11:mgmt:~#
Leaked into VRF1 with a flat/exploded mpaths
============================================
root@leaf11:mgmt:~# ip route show vrf tenant1 |grep -A3 22.1.0.7
22.1.0.7 proto bgp metric 20
nexthop via 6.0.0.11 dev vlan12 weight 1 onlink
nexthop via 6.0.0.12 dev vlan12 weight 1 onlink
nexthop via 6.0.0.13 dev vlan12 weight 1 onlink
root@leaf11:mgmt:~#
Ticket: CM-31115
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Force flush all ES-EVI PE entries when a L2-VNI is deleted. This will
implicitly free up the remote ES-EVI and deref the ES entry.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
There are two changes in this commit -
1. Maintain a list of global MAC-IP routes per-ES. This list is maintained
for quick processing on the following events -
a. When the first VTEP/PE becomes active in the ES-VRF, the L3 NHG is
activated and the route can be sent to zebra.
b. When there are no active PEs in the ES-VRF the L3 NHG is
de-activated and -
- If the ES is present in the VRF -
The route is not installed in zebra as there are no active PEs for
the ES-VRF
- If the ES is not present in the VRF -
The route is installed with a flat multi-path list i.e. without L3NHG.
This is to handle the case where there are no locally attached L2VNIs
on the ES (for that tenant VRF).
2. Reinstall VRF route when an ES is installed or uninstalled in a
tenant VRF (the global MAC-IP list in #1 is used for this purpose also).
If an ES is present in the VRF we use L3NHG to enable fast-failover of
routed traffic.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
