An operator found a situation where zebra was
backing up in a significant way towards BGP
with EVPN changes taking up some serious amounts
of memory. The key lines that would have clued
us in on it were behind a dev build. Let's change
this.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Current changes deals with EVPN routes installation to zebra.
In evpn_route_select_install() we invoke evpn_zebra_install/uninstall
which sends zclient_send_message().
This is a continuation of code changes (similar to
ccfe452763) but to handle evpn part
of the code.
Ticket: #3390099
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
When configuring a SID list by vtysh, the segment list
obtained in iproute2 is the exact opposite:
>
>vtysh:
>ipv6 route 2005::/64 eth0 segments 2001:db8:aaaa::7/2002::2/2003::3/2004::4
>
>root@r1:/# ip -6 route
>2005::/64 nhid 6 encap seg6 mode encap segs 4 [ 2004::4 2003::3 2002::2 2001:db8:aaaa::7 ] dev dummy0 proto 196 metric 20 pref medium
>
Fix this by keeping the same vtysh config and swap the
segment's order of the list in the rt_netlink.c
>
>root@r1:/# ip -6 route
>2005::/64 nhid 6 encap seg6 mode encap segs 4 [ 2001:db8:aaaa::7 2002::2 2003::3 2004::4 ] dev dummy0 proto 196 metric 20 pref medium
>
Fixes: f20cf14 ("bgpd,lib,sharpd,zebra: srv6 introduce multiple segs/SIDs in nexthop")
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
command 'show ip pim mlag summary json' should display 'mlagConnUp',
'mlagPeerConnUp', and 'mlagPeerZebraUp' when the connection is down.
Fix:
Added 'json_object_boolean_false_add()' for these objects.
Ticket: #
Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
When receiving a BGP update that includes a colored extended community,
the nexthop is tracked in the bgp nexthop tracking context, but the
color is never recorded. Adding to this, the BGP route is not prevented
from being installed without hte color.
Actually, the srte color is set only when the SRTE_COLOR attribute is set.
And that attribute value is only set when an ext. community is locally
created, or an srte value is set, but not when a BGP update with a color
ext. community is received.
Fix this by setting the SRTE_COLOR attribute on this last case.
Fixes: 442e2edcfa ("bgpd: add functions related to srte_color management")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The ISIS_SR_LAN_BACKUP should be renamed to ISIS_SR_ADJ_BACKUP.
Fixes: 26f6acafc3 ("isisd: add support for segment routing")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Add SRv6 Binding SID END.B6.Encaps nh6 str to lib.
It is used to display nh6 when one uses 'show ipv6 route'.
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
In topotest, a given interface has only the ignore routes bit turned
on for IPv6 only, whereas topotest is expected to turn it on for all
address families.
> # show interface
> Interface r2-r3-eth2 is up, line protocol is up
> [..]
> flags: <UP,BROADCAST,RUNNING,MULTICAST>
> Ignore all v6 routes with linkdown
> Type: Ethernet
> [..]
This is because the only the 'default' ipv6 ignore sysctl is set to
1. Set also the /proc/sys/net/conf/<family>/default/ignore_routes_with_linkdown
flag, to have same behaviour for ipv4 and ipv6.
Fixes: 4958158787 ("tests: micronet: update infra")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This extends non-broadcast support to point-to-multipoint networks.
Neighbors will be explicitly configured and polled in lieu of multicast
dicovery. Toptotests and documentation updates are included.
Additionally, the ospf neighbor commands have been greatly simplified taking
advantage of DEFPY() capabilities.
The AllOSPFRouters (224.0.0.5) is still joined for non-broadcast networks
since it is joined for NBMA networks. It seems this could be removed but
it should done be in a separate commit.
Signed-off-by: Acee Lindem <acee@lindem.com>
Currently bgp_path_info's are stored in reverse order
received. Sort them by the best path ordering.
This will allow for optimizations in the future on
how multipath is done.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This topotest covers the PR-15574's coverage
where a change is not to delete neighbors when
the associated peer-group's remote-as is removed.
Ticket: #3828243
Testing:
test_bgp_peer-group.py::test_bgp_peer_group
---------------------------------------------------------------------------- live log call -----------------------------------------------------------------------------
2024-03-29 18:12:22,608 INFO: r1: checking if daemons are running
2024-03-29 18:12:22,802 INFO: r2: checking if daemons are running
2024-03-29 18:12:22,911 INFO: r3: checking if daemons are running
2024-03-29 18:12:23,015 INFO: topo: Remove bgp peer-group PG1 remote-as neighbor should be retained
2024-03-29 18:12:25,605 INFO: topo: Re-add bgp peer-group PG1 remote-as neighbor should be established
----------------------------------------------------------- generated xml file: /tmp/topotests/topotests.xml -----------------------------------------------------------
========================================================================== 2 passed in 17.63s ==========================================================================
Signed-off-by: Chirag Shah <chirag@nvidia.com>
Do not reap instead let's schedule for deletion
and let best_path_selection take care of the deletion
as it should.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Currently evpn code calls bgp_best_selection for local
decisions for local tables to figure out what to do.
This is also pi based so let's note that the pi has
been changed before calling bgp_best_selection.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
