Ticket: CM-15658
Reviewed By: CCR-6534
Testing Done: Unit
Issue: frr ptm-enable command not working for interfaces that have been created by frr as a place holder.
Root Cause: The ptm-enable on interface configuration was not getting stored when the interface was internally created by frr.
Fix: Store the ptm-enable configuration even if the interface is internally created.
Signed-off-by: Radhika Mahankali <radhika@cumulusnetworks.com>
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>
Netlink messages from the kernel need to be received in a buffer larger
than 8K in order to handle some types of info - for example, the VLAN
information. Define a separate size for receive and set it to 32K, which
is the value used by other netlink receivers like iproute2.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
When zebra starts up it receives from the kernel a full dump of
interface information. Unfortunately it is in no particular order.
As such we sometimes receive data from the kernel about interfaces
we do not know about yet.
In this bug, we are attempting to use the interface pointer(->link)
for a vlan interface that we have not properly resolved.
This fix ensures that we will not attempt to call zvni_map_svi
if we have a NULL pointer. There are other places in the code
we are already checking for the fact that the ->link pointer
is valid before calling this function, so I believe that this
is correct.
We do need to come back and resolve all ->link pointers
after we have received the full table. This can be
done in another commit.
Ticket: CM-17041
Signed-off-by: Donald Sharp <sharpd@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
We have a command to enable symmetric routing only for type-5 routes.
This command is provided under vrf <> option in zebra as follows:
vrf <VRF>
vni <VNI> [prefix-routes-only]
We need the corresponding no version of the command as well as follows:
vrf <VRF>
no vni <VNI> [prefix-routes-only]
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
For ipv6 host, the next hop is conevrted to ipv6 mapped address.
However, the remote rmac should still be programmed with the ipv4 address.
This is how the entries will look in the kernel for ipv6 hosts routing.
vrf routing table:
ipv6 -> ipv6_mapped remote vtep on l3vni SVI
neigh table:
ipv6_mapped remote vtep -> remote RMAC
bridge fdb:
remote rmac -> ipv4 vtep tunnel
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
VRF static route commands adopt global static config if static config is
placed after a vrf context with no separator, workaround by always
writing static route config before vrf config
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
The range for sequence numbers needs to be limited
by the range we have currently choosen for rule
ranges.
Ticket: CM-20562
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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>
Explain the --enable-ecmp=X configure option as well as
modify the zebra user doc to explain the -e X option.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Meeting the feasibility condition is required also for routes
meeting the variance condition.
Signed-off-by: Piotr Jurkiewicz <piotr.jerzy.jurkiewicz@gmail.com>
Since we are writing into the name field which is PBR_MAP_NAMELEN
size, we are expecting this to field to be at max 100 bytes.
Newer compilers understand that the %s portion may be up to
100 bytes( because of the size of the string. The %u portion
is expected to be 10 bytes. So in `theory` there are situations
where we might truncate. The reality this is never going to
happen( who is going to create a nexthop group name that is
over say 30 characters? ). As such we are expecting the
calling function to subtract 10 from the size_t l before
we pass it in to get around this new gcc fun.
Fixes: #2163
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
re->status and re->flags both influence our decision states
for rib processing. Yet it's impossible to see them. Add
a tiny bit of code to allow us to look at them when things
are not behaving like we would expect.
Additionally dump the nexthop->flags at the same time for
the same reasons.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
