Add hook for route-map update event.
Add a delay one shot timer to accomodate route-map
update and reset redist with zebra to process
all redistribute routes with route-map info.
Cleanup route-map, prefix cached date during ospf6 exit.
Ticket:CM-13800
Testing Done:
configure redistribute connected with route-map to define
type-2 routes. Restart frr.service and validated
route-map add,update event, thread is scheduled,
once timer is done redist reset with zebra.
Upon redist add notification, all route map info is cached
in ospf6 and processed as type-2 route and send ASE E2 LSA.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
In many situations, it is desirable to only exchange EVPN routes of a particular type.
For e.g., a common deployment scenario for large DCs
is to sub-divide the DC into multiple PODs with full host mobility within a POD
(i.e., all subnets provisioned on all leaf switches within the POD)
but only do prefix-based routing across PODs.
This can be achieved by only exchanging EVPN type-5 routes across PODs.
Implement a policy to filter EVPN routes based on route type.
Ticket: CM-19394
Review: CCR-7139
Testing: Manual
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
The bestpath multipath-relax setting was added to the output of
"show ip bgp neighbor json" several months ago but this is not
the correct place to display that information and this fix removes
it from there. The multipath-relax setting was also added
to the output of "show ip bgp sum json" which is fine.
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
The code change to switch from stream_getX to STREAM_GETX added
a goto statement to be handled for a failure case. The failure
case was properly handled but the normal case was not tested
properly and there exists a situation where we would free
the out_ctxt 2 times. Prevent that from happening.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Call Route-map, prefix-list clean up routines and
vrf clearnup during ospf daemon exit routine.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Currently, while processing kernel messages related to VNIs
we first check if VNI is L3 - this is a hash lookup
later, we do the lookup again to find the L3-VNI.
This is non-optimal.
Made changed to make sure we only do the lookup once.
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
The dest->selected_fib assignment needs to happen
after the install and should be controlled by
the southbound api return of success or failure.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
If a peer already has keepalives turned on when asking to turn them on,
return immediately. Same thing for turning them off.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Use the new threading facilities provided in lib/ to streamline the
threads used in bgpd. In particular, all of the lifecycle code has been
removed from the I/O thread and replaced with the default loop. Did not
do the same to the keepalives thread as it is much smaller (doesn't need
the event system).
Also cleaned up some comments to match the style guide.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Some work on FRR's pthread wrapper.
* Provide a built-in way to synchronize thread startup
* Make utility functions take frr_pthread * instead of its integer ID
* Pass frr_pthread * as pthread start function argument
* Correct some comment styling
* Rename some variables to match naming conventions in the file
* Change parameter ordering in stop function prototype to follow the
convention in the other functions
* Default new frr_pthreads to using a vanilla event loop
For the last point, the original goal when designing the implementation
of pthreads into FRR was to be able to use the thread.c event based
system inside pthreads. This code essentially encapuslates all the
thread.c functionality into an easy to use pthread out of the box.
Creating a new frr_pthread with a null attributes field will cause the
created frr_pthread to run a thread.c event loop. The upshot of this is
that it is now possible to safely run existing functions in a pthread in
roughly 3 lines of code. It also serves as an example / starting point
for others.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
The route_node that we are working on is going to be interesting
to the kernel_route_rib_pass_fail. So I am setting up the
code to allow me to pass it. This will be done in a subsuquent
commit.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Refine the notion of what FRR considers as "configured" VRF. It is no longer
based on user just typing "vrf FOO" but when something is actually configured
against that VRF. Right now, in zebra, the only configuration against a VRF
are static IP routes and EVPN L3 VNI. Whenever a configuration is removed,
check and clear the "configured" flag if there is no other configuration for
this VRF. When user attempts to configure a static route and the VRF doesn't
exist, a VRF is created; the VRF is only active when also defined in the
kernel.
Updates: 8b73ea7bd479030418ca06eef59d0648d913b620
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Ticket: CM-10139, CM-18553
Reviewed By: CCR-7019
Testing Done:
1. Manual testing for L3 VNI and static routes - FRR restart, networking
restart etc.
2. 'vrf' smoke
<DETAILED DESCRIPTION (REPLACE)>
Ensure that spurious error messages are not generated in a non-EVPN configuration
when routes in a VRF get deleted or added. Also, check on EVPN advertisement
being enabled before walking VRF routing table.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-19206
Reviewed By: CCR-7073
Testing Done:
1. Recreate errors and validate fix
2. Type-5 route related testing - new routes, neighbor flap etc.
When a VRF gets deleted - e.g., networking restart or ifdown of the VRF - but
has associated FRR configuration, additional cleanup of all dynamic data pertaining
to this VRF is necessary. This includes the routing tables, next hop tables,
temporary queues for this VRF etc. Only the FRR configuration for this VRF must
be retained.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-19148
Reviewed By: CCR-7030
Testing Done:
1. Manual testing - This scenario and EVPN configuration
2. Various smoke tests - vrf, bgp, pim, l3-smoke
When a EVPN type-5 route is formed by using the source IP route's AS-path,
the AS-path is not locally generated and should not be "uninterned" (i.e.,
have its reference count incorrectly updated). An incorrect update of the
reference count can lead to asserts or crashes at a later stage.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Ticket: CM-19121
Reviewed By: CCR-7028
Testing Done:
1. Manual testing by Vivek and Anitha
2. No automation run since this area has no coverage yet
When shutting down, ensure that all VRFs including "configured" ones are
cleaned up properly.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-19069
Reviewed By: CCR-7011
Testing Done: Manual verification of failed scenario
When an IPv4 or IPv6 unicast route is injected into EVPN as a type-5 route
(upon user configuration), ensure that the source route (best path)'s path
attributes are used to build the EVPN type-5 route. This will result in
correct AS_PATH and ORIGIN attributes for the type-5 route so that it doesn't
appear that all type-5 routes are locally sourced. This is necessary to
ensure that external paths (IPv4 or IPv6 from EBGP peer) are preferred over
internal EVPN paths, if both exist.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Ticket: CM-19051
Reviewed By: CCR-7009
Testing Done: Verify failed scenario
Only check on L3-VNI SVI status when uninstalling remote next hops.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Ticket: CM-19036
Reviewed By: None
Testing Done:
1. Networking restart
2. VxLAN interface disable/enable
3. VRF delete and readd
A VRF is active only when the corresponding VRF device is present in the
kernel. However, when the kernel VRF device is removed, the VRF container in
FRR should go away only if there is no user configuration for it. Otherwise,
when the VRF device is created again so that the VRF becomes active, FRR
cannot take the correct actions. Example configuration for the VRF includes
static routes and EVPN L3 VNI.
Note that a VRF is currently considered to be "configured" as soon as the
operator has issued the "vrf <name>" command in FRR. Such a configured VRF
is not deleted upon VRF device removal, it is only made inactive. A VRF that
is "configured" can be deleted only upon operator action and only if the VRF
has been deactivated i.e., the VRF device removed from the kernel. This is
an existing restriction.
To implement this change, the VRF disable and delete actions have been modified.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Mitesh Kanjariya <mkanjariya@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Ticket: CM-18553, CM-18918, CM-10139
Reviewed By: CCR-7022
Testing Done:
1. vrf and pim-vrf automation tests
2. Multiple VRF delete and readd (ifdown, ifup-with-depends)
3. FRR stop, start, restart
4. Networking restart
5. Configuration delete and readd
Some of the above tests run in different sequences (manually).
We bail in the command if no l2vnis are present.
This is incorrect as we now print both l2 and l3 vnis together.
Ticket: CM-19022
Review: Trivial
Testing: Manual
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Kernel can delete a frr installed remote RMAC on a L3-VNI.
We should re-add if such a siatuation occurs
as we are the owner of the RMAC.
This behavor is same for remote MACs as well and was missing for RMACs.
Ticket: CM-18762
Review: CCR-6992
Testing: Manual
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
0. move all global EVPN details to 'show evpn [json]' command
1. change "VRF" to "Tenant VRF" in 'show evpn vni'
2. change 'show vrf vni' command to tabular form
and add l3-vni related params to the output
3. show evpn rmac should show refcount only in detailed output
4. show evpn next-hop should show refcount only in detailed output
5. move VRF in 'show evpn l3vni' to the end
6. add num rmacs and num nexthops to show evpn l3vni
7. remove "info" from 'show bgp vrf <> l3vni info'
8. show evpn vni <vni> should show l2vni details or l3 vni details
9. show evpn vni should show both L2 and L3 VNIs
10. show bgp l2vpn evpn - shows all global bgp l2vpn evpn details
11. show bgp l2vpn evpn vni - will show both l2 and l3 vnis
12. show bgp l2vpn evpn vni - should show both l2 and l3 vnis
13. follow camel notation for all json keys
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
In EVPN symmetric routing, not all subnets are presents everywhere.
We have multiple scenarios where a host might not get learned locally.
1. GARP miss
2. SVI down/up
3. Silent host
We need a mechanism to resolve such hosts. In order to achieve this,
we will be advertising a subnet route from a box and that box will help
in resolving the ARP to such hosts.
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
When doing symmetric routing,
EVPN type-2 (MACIP) routes need to be advertised with two labels (VNIs)
the first being the L2 VNI (identifying the VLAN) and
the second being the L3 VNI (identifying the VRF).
The receive processing needs to handle one or two labels too.
Ticket: CM-18489
Review: CCR-6949
Testing: manual and bgp/evpn/mpls smoke
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
1. Added default gw extended community
2. code modification to handle sticky-mac/default-gw-mac as they go together
3. show command support for newly added extended community
4. State in zebra to reflect if a mac/neigh is default gateway
5. show command enhancement to refelect the same in zebra commands
Ticket: CM-17428
Review: CCR-6580
Testing: Manual
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
