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>
When the underlying networking subsystem is fundamentally
changed via some system controls. If we have msdp running
there exists a possibility that we need to stop some running
timers to prevent a crash.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
We have run across a few cases where the startup timeout is
ocurring on heavily loaded systems. This is especially true
in simulation environments where the hypervisor load is
extremely high.
Modify the code base to give ourselves more time to startup.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The zns->ns pointer is not created until we get a callback
from the kernel that a ns exists. This should potentially
fix a crash in the *BSD code path.
Fixes: #2152
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When there are multiple advertisers/paths to reach
Intra-Prefix route, if any path is removed,
re-added back, it does add to the same route node.
ospf6 intra prefix, first stored in oa->route_table
then as part of add cb, it would add to ospf6->route_table
which adds to FIB.
When copying a route with its paths & NHs from oa->table to
ospf6->table the path origin should not be modified otherwise
ospf6->table would not find existing node rather it appends
new node.
Use spf_table to fetch nexthops for a given advertisers/path,
to form effective nexthop list for a route.
Ticket:CM-16139
Testing Done:
R2 ---- R3
| |
R1 ---- R4
Inject Intra Ara Prefix LSA from R1 & R3, validate R2 and R4
having two origination point/paths to reach for a route.
Trigger link flap, frr restart or remove/readd R3's INP one of the
injection point.
Remove link between R4 to R1 and validate R3 carrying single
path to reach prefix.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Customers have requested the ability to name their devices starting
with a number instead of a letter. This fix changes the check for
hostname to allow either a letter or a number.
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
