Ensure that the next hop of the leaked VRF is not overwritten when the
route is being imported into the target VRF from the VPN table. Also, in
the case of multipath routes, ensure that the nexthop's ifindex is not
inadvertently reset.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
There are situations in which zebra may issue more than one delete
notification, so BGP should not warn when it can't locate the VNI
at delete. This is comparable to the situation when a withdraw is
received but the route isn't present locally.
Signed-off-by: Vivek Venkatraman <vivek@cumulusmetworks.com>
Ticket: CM-17512
Reviewed By: Trivial
Testing Done: Manual
This flag needs to be set by default for l2vpn evpn address-family.
We needed to find a place in the code which gets called by all peers
at somepoint in the statemachine and before the routes are advertised.
peer_new seems like the right place for this
as we are setting other default af_flags here as well.
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
In the FRR implementation of EVPN,
eBGP leaf-spine peering for EVPN is fully supported by allowing
the next hop to be propagated and not rewritten at each hop.
There are other changes also related to route import to facilitate this.
However, propagating the next hop is not correct in some cases.
Specifically, if the DC is comprised of multiple PODs
with distinct intra-POD and inter-POD VxLAN tunnels,
EVPN routes received from an adjacent POD by a border/exit leaf
must be propagated into the local POD with the next hop rewritten (to self).
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
We install type-5 routes as ipv4/ipv6 unicast routes in the vrf table.
along with these routes, we also install the RMAC
and the nexthop Neigh entries.
There might be scenarios were the bestpath has changed and
we are now pointing to a new nexthop with a different RMAC.
As per BGP logic, we just send an update for the route and the nexthop
is replaced. However, this causes problem because the RMAC and neigh entry
corresponding to the previous nexthop are still lingering in the system.
We need to clear those entries for proper functoning.
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
A newly added ipv4/ipv6 route in BGP RIB might be advertised as type-5 EVPN route.
The user might have configured a route-map for advertising type-5 routes.
We need to apply this route-map while advertising ipv4/ipv6 routes as type-5.
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
We enable/disable type-5 routes by following commands:
advertise ipv4 unicast [route-map <route-map>]
advertise ipv6 commands [route-map <route-map>]
the route-map part was writtem to conf file.
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
no advertise ipv6 unicast command should unset the corresponding
af_flag in bgp_vrf rather than the vrf_flags.
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Display the table version for EVPN routes like it is done for other
address families. Note that this is really relevant only for the
per-VNI routing table.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Ticket: CM-12903
Ensure that when EVPN routes are installed into zebra, the router MAC
is passed per next hop and appropriately handled. This is required for
proper multipath operation.
Ticket: CM-18999
Reviewed By:
Testing Done: Verified failed scenario, other manual tests
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Upon BGP destroy, the hash list related to PBR are removed.
The pbr_match entries, as well as the contained pbr_match_entries
entries.
Then the pbr_action entries. The order is important, since the former
are referencing pbr_action. So the references must be removed, prior to
remove pbr action.
Also, the zebra associated contexts are removed.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Upon redirect VRF message from FS, add a default route to the VRF
interface associated to the VRF.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
A table chunk of 100000 is allocated from zebra, and when needed in
flowspec, the table identifier is extracted from that chunk.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
If a new rule is identified, a new table identifier is created.
In that table, add a default route when possible. If redirect IP rule is
identified, then add a default route to that IP address.
If redirect VRF is identified, nothing is done for now
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
once an iprule has been created, a notification is sent back, and the
context of bgp_action is searched.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This commit is reading the installed2 value from bgp_pbr_match hash set.
Once value matches with the one received, the walk stops and the last
bgp_pbr_match structure is stored in a static entry, so that the entry
is obtained.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Once the bgp flowspec entry is validated, then that means that zebra is
able to handle the entries.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The API for filling in an IPTABLE_ADD and IPTABLE_DELETE message.
Also, the API is handling the notification callback, so as to know if
zebra managed to add or delete the relevant iptable entry.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Add a policy-route API to handle flowspec entry.
The entry is analysed, converted, and
selected if it is possible to inject the flowspec entry in local policy
routing entries.
redirect IP and redirect VRF actions are handled. The former extracts
the IPv4 address to redirect traffic to. The latter calculates the
matching VRF to redirect traffic to.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This utility routine in bgp ecommunity converts the flowspec actions
into a readable format in a policy routing action context.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This utility function analyses flowspec nlri and converts it into
readable structures. The structure is based on bgp_pbr_match structure
previously defined.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This structure is the model exchange between some bgp services like
flowspec and the policy routing service. This structure reflects what
the nlri entry means. To handle that structure, a dump routine is made
available. Also, a validation function is here to cancel a policy route
installation, whenever it is not possible to install the requested
policy routing.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This command is used to troubleshoot the routes that are installed inbgp
pbr fib, before being injected in zebra.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
bgp structure is being extended with hash sets that will be used by
flowspec to give policy routing facilities.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The APIs that handle ipset and iprule contexts from zebra are being
handled in this commit.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
BGP flowspec will be able to inject or remove policy-routing contexts,
thanks to some protocols like flowspec. This commit adds some the APIS
necessary to create/delete policy routing contexts that will be injected
then into zebra.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
As part of recent vpn-vrf leaking changes, it is now possible for a
route to refer to a nexthop in a different vrf. There is also a new
route flag that means "when announcing this route, indicate myself
as the next-hop."
route_vty_out(): nexthops are appended with:
"@VRFID" (where VRFID is the numerical vrf id) when different from
the route's vrf;
"<" when the route's BGP_INFO_ANNC_NH_SELF is set
This change also shows the route table's vrf id in the table header.
route_vty_out_detail(): show nexthop's vrf and announce-nh-self flag if
appropriate.
Both functions are also augmented to add json elements nhVrfId, nhVrfName,
and announceNexthopSelf as appropriate.
The intent of these changes is to make it easier to understand/debug
the relationship between a route and its nexthops.
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
The vrf 2 vrf route leaking auto-derives RD and RT and
installs the routes into the appropriate vpn table.
These routes when a operator configured ipv[4|6] vpn
neighbors were showing up off box. The RD and RT
values choosen are localy significant but globaly
useless and may cause confusion.
Put a special bit of code in to notice that we
should not be advertising these routes off box.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This commit reverts part of ceb800e0edb9f8979cebb1e6be9497d787bee39c
as it was found to be causing issues in upstream CI.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The loop over all afi's implies that these commands actually need
to loop over all afi's to check the vpn policy. We know the
appropriate afi based upon the node we are in. So just return
the correct afi to look at and then just apply it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Prior to this fix, you could configure importing a vrf from inside
the same vrf. This can lead to unexpected behavior in the leaking
process. This fix disallows that behavior.
Ticket: CM-20539
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Tripped over a crash running the cli_crawler that occurred when the
sequence was doing "import vrf NAME" and "no import vrf NAME" inside
a vrf but a default bgp instance had not been created. This fix
auto-creates the default instance if the "import vrf NAME" is
entered and a default instance does not exist.
Ticket: CM-20532
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Prior to this fix, the import vrf route-map command only worked
if the route-map existed prior to the command. Additionally, if
the import vrf route-map command was issued without an existing
route-map, the imported prefixes were not removed. This fix
resolves both of thes mis-behaviors. bgp-smoke run with same
failures as base.
Ticket: CM-20459
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: CCR-7358
Found that when doing "import vrf default" in another vrf, an
extra line was added to the configuration in error. This fix
resolves that incorrect configuration. Manual testing will be
attached to the defect.
Ticket: CM-20467
Signed-off-by: Don Slice <dslice@cumulustnetworks.com>
Reviewed by: Donald Sharp <sharpd@cumulusnetworks.com>
The usage of MTYPE_ECOMMUNITY for the free in ecommunity_del_val
caused the ref counts for the ecommunity to be incorrect.
Use MTYPE_ECOMMUNITY_VAL since that is what we are deleting.
Ticket: CM-20602
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
There were a couple of instances of code extending
beyond 80 columns, clean it up with clang-format.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Note that when we are importing vrf EVA into vrf DONNA
we must keep track of all the vrfs EVA is being
exported into and we must also keep track of all the vrf's
that DONNA is receiving data from as well.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The data type for a variable in bgp_ecommunity.c was
a non-standard type and was causing build failures
on some more obscure build targets.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
