When a user specifies static routes, there are a couple of states
where we will store the route and display it as part of the 'show run'
but it will not be installed until such time that the dependant state
is created. Add some breadcrumbs to the user so that they can figure
out WTF just happened.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Holdem statics display the dest (and mask, if present) string that the
user entered instead of converting to CIDR notation and applying the
mask. They need to do the latter.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Prevent zebra from crashing for when the nexthop vrf has
changed in some manner and the lookup fails.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When a user enables and disables a vrf, we were not
properly cleaning up the static routes leaving us
in a state where we would crash by looking at anything
in zebra.
On disable of a vrf -> Search through all static routes
and if the nexthop vrf is the disabled vrf uninstall it.
Additionally uninstall all static routes in that zvrf
On enable of a vrf -> Search through all static routes
and if the nexthop vrf is the enabled vrf install it.
Additionally install all the static routes in that zvrf.
Ticket: CM-19768
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The following types are nonstandard:
- u_char
- u_short
- u_int
- u_long
- u_int8_t
- u_int16_t
- u_int32_t
Replace them with the C99 standard types:
- uint8_t
- unsigned short
- unsigned int
- unsigned long
- uint8_t
- uint16_t
- uint32_t
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
This patch fixes two bugs with respect to static route configuration
inside vrf contexts:
* Entering a negative form of a static route created the static route.
* Once created, static routes could not be deleted.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
When we have a case where the user re-enters the same
ip route line, we need to delete the memory we just
malloc'ed.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When specifying a ip route:
ip route 4.3.2.0/24 192.168.201.1 vrf DONNA
Accept DONNA even if it has not been created yet.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
If a user enters a route inside a non kernel existant vrf:
vrf BLOOP
ip route 4.3.2.0/24 192.168.201.1
!
They should be able to enter it over and over and over and
over and over no matter how futile it is.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Currently if I try to use a nexthop-vrf that has
not been specified yet we get a failure from the cli.
Add code to zebra so that if we fail to find the nexthop-vrf
we auto create it, instead of failing the install.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Also modify `struct route_entry` to use nexthop_groups.
Move ALL_NEXTHOPS loop to nexthop_group.h
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When zebra is being configed we allow for static routes
to be entered. This presents a problem for when a vrf
is cli configed but not kernel configed yet.
Modify zebra to notice that when a static route is
entered and either the nexthop vrf or the vrf
is not fully configed, to save that config to the
side.
When vrf's become active( kernel configed ) parse
through the list of saved to the side static routes
and determine if any of them can be installed.
Additionally modify the cli to output the saved
to the side cli, so that we can properly handle
a wr mem.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Show vrf command displays information on the vrf, if it is related to
vrf kernel or if it is related to netns.
When a vrf from kernel is detected, before creating a new vrf, a check
is done against an already present vrf, and if that vrf is not a vrf
mapped with a netns. If that is that case, then the creation is
rejected.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
With the ability of zebra to handle random tables,
add code to display those tables via the
show <ip|ipv6> route table (1-...) [json] command.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
1) Add asserts in a couple of spots to show we
never expect prefix to be bad.
2) Fix some bfd code where out_ctxt will
always be NULL.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Asymmetric routing is an ideal choice when all VLANs are cfged on all leafs.
It simplifies the routing configuration and
eliminates potential need for advertising subnet routes.
However, we need to reach the Internet or global destinations
or to do subnet-based routing between PODs or DCs.
This requires EVPN type-5 routes but those routes require L3 VNI configuration.
This task is to support EVPN type-5 routes for prefix-based routing in
conjunction with asymmetric routing within the POD/DC.
It is done by providing an option to use the L3 VNI only for prefix routes,
so that type-2 routes (host routes) will only use the L2 VNI.
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Turns out we had 3 different ways to define labels
all of them overlapping with the same meanings.
Consolidate to 1. This one choosen is consistent
naming wise with what the *bsd and linux kernels
use.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Fix the read in of vrf routes on a start or restart that caused
the nexthop_vrf to be assumed to be the default vrf.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The v6 code had the same issue with how it handled
nexthop-vrf and nexthop when it was entered on the
same line. This fixes that issue.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The error handling of the nexthop vrf and the vrf
for what was specified on the cli was not as clean
as it should have been.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The nexthop_vrf should be looked up as appropriate,
If the nexthop_vrf was specified use that, else
use the vrf context of what was passed in.
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)>
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>
On some places of code, the VRF_DEFAULT define was not used. This commit
is ensuring that the macros is well used.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Move the code that generates the 'show run' output for
'ip route' to be controlled by the vrf config generation
code. Since it really belongs there.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
If the vrf for the nexthop is different than the vrf the
route is in, display the nexthops vrf.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When displaying a specific route and if it has a tag
and if we have turned on realm support notify the user
that a tag value of (1-255) is installed into the kernel
with the realm set.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
zserv.c has become a bit of a dumping ground for zebra cli.
I'd like to focus the zserv.c code into it's core functionality
which is handling the zapi interface.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The SELECTED_FIB flag was placed upon the entry that we
have inserted into the kernel. Remove this flag and replace
with a `rib_dest_t` *selected_fib. Just keep track of the
selected_fib as we modify it. This removes allot of
FOREACH_RE loops as that we do not need to find the
entry anymore.
At this point in time I think this is a very minor performance
boost. Most `rib_dest_t` structures do not typically carry
more than 1 route_entry, but the minute you start having more
than one entry you can and will start having significant processing
time spent finding the selected_fib.
A future commit may re-order the route entries and possibly
keep more pointers on `rib_dest_t` to avoid lookup. This
is a bit tricky because of the FIB_OVERRIDE code.
Signed-off-by Donald Sharp <sharpd@cumulusnetworks.com>
Rework of do_show_ip_route caused the 'show ip rpf'
cli to stop working. This put's it back into working
order.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The original clippy implementation used if VTYSH_EXTRACT_PL
was defined or not to know to include as part of the creation
of vtysh.
Follow their lead here.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Allow the end user to specify how many packets we want
to process at one time coming down the zapi, before
we yield and let other things process.
This is a Hidden command because it is not necessarily
something that we want end users to be able to play with
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Allow the user to modify the work-queue processing hold time
from 10ms to a value from (0-10000). Make the command hidden
as that it's a semi-dangerous command and it could cause
issues.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Now it's possible to specify multiple options when viewing the RIB or
FIB.
Example: 'show ip route 192.168.0.0/16 longer-prefixes tag 10 ospf'
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Note: I had to remove one assert in clidef.py in order to fix a build
error when using a preprocessor string (FRR_IP_REDIST_STR_ZEBRA) inside
a DEFPY command. This should be revisited later.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This fixes the broken indentation of several foreach loops throughout
the code.
From clang's documentation[1]:
ForEachMacros: A vector of macros that should be interpreted as foreach
loops instead of as function calls.
[1] http://clang.llvm.org/docs/ClangFormatStyleOptions.html
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Display uptime for all route types instead of just for RIP,
OSPFv2, ISIS, NHRP, TABLE? and BGP routes.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add the ability for person issuing 'show ip route...' commands
to see if we've suppressed adding a nexthop to the kernel.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
If we configure a static route pointing to null0 and zebra displays
it with the 'blackhole' keyword in the running configuration, the
frr-reload.py script will have issues. Fix this by introducing the
'static_blackhole_type' enum.
Fixes#1091.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This reference counter was introduced in 2001, apparently to solve a
problem with connected routes being added/removed multiple times. The RIB
code changed a lot since then, and giving the current callers of rib_add()
and rib_delete() it's safe to assume that we don't need this anymore.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
blackhole support was horribly broken. cleanup by removing blackhole
stuff from ZEBRA_FLAG_*
introduces support for "prohibit" routes (Linux/netlink only)
also clean up blackhole options on "ip route" vty commands.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Bug introduced a couple of weeks ago by myself. Only happens when the
route has an IP nexthop + a nexthop interface.
Example:
debian(config)# ip route 10.0.1.0/24 172.16.1.10 fake1
debian(config)# do sh run
Building configuration...
[snip]
!
ip route 10.0.1.0/24 172.16.1.10 unknown
!
end
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The defines:
ONE_DAY_SECOND
ONE_WEEK_SECOND
ONE_YEAR_SECOND
were being defined all over the system, move the
define to a central location.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Whenever an interface is created or deleted in the system, we need to
check whether we have static routes referencing that interface by name.
If so, we need to [un]install these routes.
This has the unfortunate side effect of making static routes with
non-existent interfaces disappear from "show ip route", but I think
that's acceptable (and I don't see a "good" fix for that).
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Now we have a single command for IPv4 static routes and another one for
IPv6 static routes (+ one command for IPv4 multicast static routes).
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Fully specified routes are useful when you need to ensure that the
nexthop address is reachable through the specified interface.
Addresses Issue #641.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This is a preliminary step to join both functions into one later.
The main idea here is to make these functions have separate arguments
for the nexthop address and the nexthop interface, and adjust the call
sites appropriately. Having an argument that could be a nexthop address
OR a nexthop interface was making the code very hard to follow. With
this simplification, a lot of code duplication was removed and now both
functions look very similar.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
We don't need to enforce that the interface exists because the route can
be activated later once the interface becomes available. We already do
this for IPv4 routes and IPv6 routes with both a nexthop address and a
nexthop interface.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
