Nitin Soni [Thu, 24 Jan 2019 08:44:42 +0000 (00:44 -0800)]
ospfd: ospfd core if hello packet exceeds link MTU
Ospfd cored because of an assert when we try to write more than the MTU
size to the ospf packet buffer stream. The problem is - we allocate only MTU
sized buffer. The expectation is that Hello packets are never large
enough to approach MTU. Instead of crashing, this fix discards hello and
logs an error. One should not have so many neighbors behind an
interface.
Ticket: CM-22380 Signed-off-by: Nitin Soni <nsoni@cumulusnetworks.com> Reviewed-by: CCR-8204
Donald Sharp [Wed, 28 Nov 2018 23:46:36 +0000 (18:46 -0500)]
bgpd: interface based peers should automatically override it's peer group
When a interface based peer is setup and if it is part of a peer
group we should ignore this and just use the PEER_FLAG_CAPABILITY_ENHE
no matter what.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Wed, 28 Nov 2018 23:21:08 +0000 (18:21 -0500)]
bgpd: Fix crash in various 'show bgp neighbor json' commands
bgp would crash with various `show bgp neighbor json` commands
based upon whether or not it did a pretty print of the output
or not. This is because we were freeing the data 2 times.
Cleanup so that we free the json data 1 time.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Mon, 14 Jan 2019 21:37:53 +0000 (16:37 -0500)]
zebra: Use ROUTE_ENTRY_INSTALLED as decision for route is installed
zebra is using NEXTHOP_FLAG_FIB as the basis of whether or not
a route_entry is installed. This is problematic in that we plan
to separate out nexthop handling from route installation. So modify
the code to keep track of whether or not a route_entry is installed/failed.
This basically means that every place we set/unset NEXTHOP_FLAG_FIB, we
actually also set/unset ROUTE_ENTRY_INSTALLED on the route_entry.
Additionally where we check for route installed via NEXTHOP_FLAG_FIB
switch over to checking if the route think's it is installed.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Tue, 15 Jan 2019 12:21:22 +0000 (07:21 -0500)]
zebra: Fix use before initialized
When we discover that a command given to the route add/delete
function in rt_socket.c is bogus, print out a debug message
but don't attempt to actually use a nexthop that we have not
figured out yet as part of the data.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Tue, 15 Jan 2019 12:26:00 +0000 (07:26 -0500)]
zebra: Having one goto in a function to just return is silly
Just return right there, goto's are useful if you have common
code that needs to be cleaned up before exiting this function,
of which this function has none and there is only one goto.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Chirag Shah [Thu, 24 Jan 2019 20:19:53 +0000 (12:19 -0800)]
zebra: fix dup addr detect remote macip add case
A MACIP is detected as duplicate and after that
the host continue to move behind different VTEPs results
in local VTEP receiving remote mobility events.
In remote_macip_add, ensure to trigger dad if
MAC is marked as duplicate. In case of freeze
action enabled, is_dup_detect will be set to
avoids installing frozen MAC into kernel.
Ticket:CM-23649
Testing Done:
Configured detection action freeze with detection count
as 7 at DUT and >7 at remote VTEP,
trigger MAC-IP mobility between VTEPs.
once tdetection count reached, MAC detected as duplicate,
post detection move the host to remote. The local VTEP
receives remote macip add and entry is not installed into
kernel with fix.
root@VTEP1:~# net show evpn mac vni 1002 mac aa:aa:aa:aa:aa:aa
MAC: aa:aa:aa:aa:aa:aa
Remote VTEP: 27.0.0.16
Local Seq: 7 Remote Seq: 8
Duplicate, detected at Fri Jan 25 05:03:29 2019
Neighbors:
11.11.11.11 Inactive
Kernel entry still points to LOCAL
root@VTEP1:~# bridge fdb show | grep aa:aa:aa
aa:aa:aa:aa:aa:aa dev hostbond3 vlan 1002 master VxLanA-1
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
In a VRR/VRRP setup we can have connected routes with different costs.
So this change eliminates suppressing metric display for connected routes.
Sample output -
root@TORC11:~# vtysh -c "show ipv6 route vrf vrf1"
Codes: K - kernel route, C - connected, S - static, R - RIPng,
O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table,
v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR,
> - selected route, * - FIB route
VRF vrf1:
K * ::/0 [255/8192] unreachable (ICMP unreachable), 00:00:36
C * 2001:aa:1::/64 [0/100] is directly connected, vlan1002-v0, 00:00:36
C>* 2001:aa:1::/64 [0/90] is directly connected, vlan1002, 00:00:36
zebra: set connected route metric based on the devaddr metric
MACVLAN devices are typically used for applications such as VRR/VRRP that
require a second MAC address (virtual). These devices have a corresponding
SVI/VLAN device -
root@TORC11:~# ip addr show vlan1002
39: vlan1002@bridge: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9152 qdisc noqueue master vrf1 state UP group default
link/ether 00:02:00:00:00:2e brd ff:ff:ff:ff:ff:ff
inet6 2001:aa:1::2/64 scope global
valid_lft forever preferred_lft forever
root@TORC11:~# ip addr show vlan1002-v0
40: vlan1002-v0@vlan1002: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9152 qdisc noqueue master vrf1 state UP group default
link/ether 00:00:5e:00:01:01 brd ff:ff:ff:ff:ff:ff
inet6 2001:aa:1::a/64 metric 1024 scope global
valid_lft forever preferred_lft forever
root@TORC11:~#
The macvlan device is used primarily for RX (VR-IP/VR-MAC). And TX is via
the SVI. To acheive that functionality the macvlan network's metric
is set to a higher value.
Zebra currently ignores the devaddr metric sent by the kernel and hardcodes
it to 0. This commit eliminates that hardcoding. If the devaddr metric
is available (METRIC_MAX) it is used for setting up the connected route
otherwise we fallback to the dev/interface metric.
Setting the macvlan metric to a higher value ensures that zebra will always
select the connected route on the SVI (and subsequently use it for next hop
resolution etc.) -
root@TORC11:~# vtysh -c "show ip route vrf vrf1 2001:aa:1::/64"
Routing entry for 2001:aa:1::/64
Known via "connected", distance 0, metric 1024, vrf vrf1
Last update 11:30:56 ago
* directly connected, vlan1002-v0
Routing entry for 2001:aa:1::/64
Known via "connected", distance 0, metric 0, vrf vrf1, best
Last update 11:30:56 ago
* directly connected, vlan1002
bgpd: reinstate current bgp best route on an inactive neigh del
When an inactive-neigh delete is rxed bgp will not have a local path to
remove (and re-run path selection). Instead it simply re-installs the
current best remote path if any.
When a local neigh is added with a MAC that is remote or absent the
neigh is kept in zebra as local/in-active. But not propagated to bgpd.
Similarly when an inactive neigh is deleted the del-msg is not propagated
to bgpd.
Without this change bgp and zebra would fall out of sync as that
bgp would not know to rerun bestpath and for it to reinstall a
known remote path for the mac-ip in question. To fix this we
now propagate inactive neigh deletes to bgpd.
Ticket: CM-23018
Testing Done:
1. evpn-min
2. manually triggered the out-of-sync state and verified the fix
bgpd: fill the zebra mac-ip route via a common api
Move the info filling for zebra mac-ip install (sent by bgpd) to a
common place.
The commit also fixes missing ROUTER flag for one of the cases
added in a code branch that doesn't have the ROUTER changes -
[ 6d8c603a
bgpd: use IP address as tie breaker if the MM seq number is the same
]
Donald Sharp [Fri, 25 Jan 2019 16:57:09 +0000 (11:57 -0500)]
pimd: Prevent crash from using pim static mroutes
If you have an interface being added to a static mroute
and that interface has been configured w/ pim but does
not have a valid ip address yet, we do not create a
VIF for that device yet. As such when we attempt
to assign the vif array in the pim static data structure
we attempt to write into -1 of that array.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
David Lamparter [Fri, 30 Nov 2018 20:42:25 +0000 (21:42 +0100)]
build, lib/yang: bake in extensions if possible
Starting with libyang 0.16.74, we can load internally embedded yang
extensions instead of going through the file system/dlopen. Detect
support for this at build time and use if available.
NB: the fallback mechanism will go away in a short while.
Signed-off-by: David Lamparter <equinox@diac24.net>
Donald Sharp [Tue, 22 Jan 2019 12:39:14 +0000 (07:39 -0500)]
zebra: Add code to track sequence number from zebra_router
The sequence number used should be unique and increase by 1
for netlink commands. This will allow the code to match
up batched commands to actual requests, so that we can signal
the failure correctly back.
So start the movement and tracking of sequence numbers as
an atomic uint32_t in zebra_router. Modify the dataplane
code to start tracking contexts from this value.
In future commits we will move more of the sequencing
data into using this value.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Nitin Soni [Thu, 24 Jan 2019 09:43:48 +0000 (01:43 -0800)]
bgpd: route-map fails to filter type-5 routes
Route-map filtering is based on the value of
"bgp->adv_cmd_rmap[afi][safi].map". For example, we advertise routes in
bgp_evpn_advertise_type5_routes() based on the value of
"bgp->adv_cmd_rmap[afi][safi].map". This variable gets populated in vty
handler bgp_evpn_advertise_type5. This variable will not get populated
if we have not yet applied the route-map configuration. The fix is to
correctly populate "bgp->adv_cmd_rmap[afi][safi].map" in
bgp_route_map_process_update() if it has not been populated before.
Ticket: CM-23263 Signed-off-by: Nitin Soni <nsoni@cumulusnetworks.com> Reviewed-by: CCR-8163
Ruben Kerkhof [Tue, 22 Jan 2019 17:32:08 +0000 (18:32 +0100)]
Redirect output of ranlib to /dev/null
./configure on Mac OS logs:
checking whether ranlib supports D option... error: /Library/Developer/CommandLineTools/usr/bin/ranlib: unknown option character `D' in: -D
Usage: /Library/Developer/CommandLineTools/usr/bin/ranlib [-sactfqLT] [-] archive [...]
no
Ruben Kerkhof [Tue, 22 Jan 2019 17:29:29 +0000 (18:29 +0100)]
Redirect output of $AR check to /dev/null
./configure logs this on Mac OS:
checking whether ar supports D option... /Library/Developer/CommandLineTools/usr/bin/ar: illegal option -- D
usage: ar -d [-TLsv] archive file ...
ar -m [-TLsv] archive file ...
ar -m [-abiTLsv] position archive file ...
ar -p [-TLsv] archive [file ...]
ar -q [-cTLsv] archive file ...
ar -r [-cuTLsv] archive file ...
ar -r [-abciuTLsv] position archive file ...
ar -t [-TLsv] archive [file ...]
ar -x [-ouTLsv] archive [file ...]
no
This is quite noisy and we're only interested in the result of the
check, not the output.
Rafael Zalamena [Wed, 23 Jan 2019 12:25:30 +0000 (10:25 -0200)]
ospf6d: keep track of the socket set thread
When using the timer to set the socket multicast options, keep track
of the thread pointer. If we lose the thread reference we might have
situations where multicast is enabled when it should be disabled and
vice versa.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Don Slice [Thu, 27 Dec 2018 16:03:38 +0000 (11:03 -0500)]
bgpd: improve peer-group remote-as definitions
Problem reported that with certain sequences of defining the
remote-as on the peer-group and the members, the configuration would
become wrong, with configured remote-as settings not reflected in
the config but peers unable to come up. This fix resolves these
inconsistencies.
Ticket: CM-19560 Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Donald Sharp [Wed, 23 Jan 2019 01:00:55 +0000 (20:00 -0500)]
topotests: Modify bgp convergence to be more than 120 seconds
Waiting 10 seconds for bgp convergence makes no sense, especially
if the test system is under load and a node is started up before
the node it is connecting to is up. We should wait for the full
default of 120 seconds, plus a little time to ensure nothing is
screwed up too much.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Renato Westphal [Tue, 22 Jan 2019 19:50:33 +0000 (17:50 -0200)]
ldpd: fix corner case in which we wouldn't respect the max pdu length
The calculation to know when an LDP PDU went past the maximum
negotiated PDU length was wrong because it wasn't taking the
"Version" and "PDU Length" fields into account (total of four
bytes). Fix this.
Mark Stapp [Tue, 23 Oct 2018 14:57:01 +0000 (10:57 -0400)]
zebra: infra for LSP updates using dplane
Adding infra to zebra dplane to support LSP updates. Add
kernel api for LSP updates that uses a dataplane context; add
stub apis for netlink, bsd, and 'null' kernel paths. Add
version of netlink mpls update code that takes a dplane
context struct instead of a zebra lsp struct.
Mark Stapp [Wed, 17 Oct 2018 19:54:53 +0000 (15:54 -0400)]
zebra: add apis to add and delete NHLFEs
Add public versions of zebra apis that add NHLFEs to an LSP,
and that free NHLFEs. The dataplane code needs to capture/copy
NHLFEs in order to do async LSP programming.
Ruben Kerkhof [Tue, 22 Jan 2019 16:55:31 +0000 (17:55 +0100)]
Fix compile error on Mac OS
CC lib/frr_pthread.lo
lib/frr_pthread.c:128:40: error: too many arguments to function call, expected 1, have 3
ret = pthread_setname_np(fpt->thread, fpt->os_name, NULL);
~~~~~~~~~~~~~~~~~~ ^~~~~~~~~~~~~~~~~~
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/pthread.h:512:1: note: 'pthread_setname_np' declared here
__API_AVAILABLE(macos(10.6), ios(3.2))
Mac OS does have pthread_setname_np, but we can't use it here since it
only accepts a single argument, the thread name, and thus only works for
the current thread.
Rafael Zalamena [Thu, 17 Jan 2019 22:46:11 +0000 (20:46 -0200)]
zebra: fix routing socket AF_LINK handling on NETMASK
IPv6 netmasks use AF_LINK family type and puts the correct amount of
set bits in the data structure. If we only copy the SDL header we
won't get all IPv6 address length, we must copy the whole extension of
the `sockaddr_in6` struct (which is provided in `destlen` parameter).
Philippe Guibert [Mon, 21 Jan 2019 16:19:53 +0000 (17:19 +0100)]
bgpd: do not crash when removing ip vpn entries
when removing bgp instance, the parsing of rm->info contexts must be
protected. Also, the main level of hierarchy of rds must not be
allocated more than once.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Renato Westphal [Mon, 21 Jan 2019 14:30:36 +0000 (12:30 -0200)]
zebra: consolidate how we indentify address-families in the NHT code
Favor usage of the afi_t enumeration to identify address-families
over using the classic AF_INET[6] constants for that. The choice to
use either of the two seems to be mostly arbitrary throughout our
code base, which leads to confusion and bugs like the one fixed by
commit 6f95d11a1. To address this problem, favor usage of the afi_t
enumeration whenever possible, since 1) it's an enumeration (helps
the compilers to catch some bugs), 2) has a safi_t sibling and 3)
can be used to index static arrays. AF_INET[6] should then be used
only when interfacing with the kernel or external libraries like
libc. The family2afi() and afi2family() functions can be used to
convert between the two different representations back and forth.
Renato Westphal [Sat, 19 Jan 2019 19:24:09 +0000 (17:24 -0200)]
python: make DEFPY provide the text token of fixed parameters
In the CLI code, each cmd_token has both a "text" field, containing
the full token text (e.g. "unicast"), and an "arg" field,
containing the original text entered by the user (which might be
an abbreviation, like "uni" instead of "unicast").
To avoid the need to handle abbreviations, the recommended pattern
for DEFUN commands is to use the "text" value of fixed parameters
and the "arg" value of everything else.
Using DEFPY, however, the CLI parameters are automagically turned
into C variables which are initialized under the hood (so that
they're conveniently ready for use). The problem is that this
initialization was always using the "arg" value of the parameters,
which was leading to problems like these:
debian# show ipv6 route isi
Unknown route type
debian#
debian# conf t
debian(config)# router isis 1
debian(config-router)# redistribute ipv4 st level-1
% Configuration failed.
Invalid value "st" in "protocol" element.
YANG path: /frr-isisd:isis/instance[area-tag='1']/redistribute/ipv4[protocol='st']/protocol
To fix these problems (and probably others too), make DEFPY commands
auto-detect the type of the input parameters and use either the
"arg" or "text" value from the cmd_tokens accordingly.
Renato Westphal [Sat, 19 Jan 2019 19:19:13 +0000 (17:19 -0200)]
lib: remove the vrf_is_mapped_on_netns() function
Now that all daemons receive the VRF backend from zebra, we can get
rid of vrf_is_mapped_on_netns() in favor of using the more convenient
vrf_is_backend_netns() function, which doesn't require any argument.
This commit also fixes the following problem:
debian(config)# ip route 50.0.0.0/8 blackhole vrf FAKE table 2
% table param only available when running on netns-based vrfs
Even when zebra was started with the --vrfwnetns, the error
above would be displayed since the VRF FAKE didn't exist, which
would make vrf_is_mapped_on_netns() return 0 incorrectly. Using
vrf_is_backend_netns() this problem doesn't happen anymore.
Renato Westphal [Sat, 19 Jan 2019 19:19:13 +0000 (17:19 -0200)]
zebra, lib: send VRF backend to the client daemons
Add a new field in the ZEBRA_CAPABILITIES zapi message specifying
the VRF backend in use.
For simplicity, make the zclient code call vrf_configure_backend()
to apply the received value automatically instead of requiring
the daemons to do that themselves in their zebra_capabilities()
callbacks.
Additionally, call zebra_vrf_update_all() only after sending the
capabilities message to the client, so that it will know which VRF
backend is in use when processing the VRF messages.
This commit fixes a couple of bugs in the "interface" CLI command and
associated northbound callbacks, which behave differently depending
on the VRF backend in use. Before this commit, the vrf_backend
variable would always be set to VRF_BACKEND_NETNS in the client
daemons, even when zebra was started without the --vrfwnetns option.
This could lead to inconsistent behavior and subtle bugs under
specific circumstances.
Renato Westphal [Sat, 19 Jan 2019 01:23:45 +0000 (23:23 -0200)]
lib: simplify detection of when the user is leaving the CLI config mode
We can make use of the vty->config variable to know when the CLI
user is in the configuration mode or not. This is much simpler
than obtaining this information from the vty node, and also a more
robust solution (the three switch statements below, for example,
were out of sync).
Also, fix a bug where vty->config wasn't being unset in the
vty_config_exit() function (bug introduced by commit f344c66ea3).
Renato Westphal [Sat, 19 Jan 2019 00:58:58 +0000 (22:58 -0200)]
lib: reset the vty xpath index when entering the config mode
The CLI code uses the vty->xpath[] array and the vty->xpath_index
variables to keep track of where the user is in the configuration
hierarchy. As such, we were resetting vty->xpath_index to zero
whenever the user exited from the configuration mode in order to
keep the index valid. We weren't doing this in the vty_stop_input()
function however, which is called when the user types ^C in the
terminal. This was leading to bugs like this:
zebra> en
zebra# conf t
zebra(config)# interface eth0
zebra(config-if)# ^C
zebra# conf t
zebra(config)# interface eth0
% Configuration failed.
Schema node not found.
YANG path: /frr-interface:lib/interface[name='eth0'][vrf='default']/frr-interface:lib
To fix this, do something more clever: instead of resetting the
XPath index whenever the user exits from the configuration mode,
do that when the user enters in the configuration mode. This way
the XPath index needs to be reset in a single place only, not to
mention it's a more robust solution.
Renato Westphal [Fri, 18 Jan 2019 18:06:00 +0000 (16:06 -0200)]
zebra: send link parameters to zclients once they request interface info
We were sending ZEBRA_INTERFACE_LINK_PARAMS messages under the
following circumstances:
* New interface was created (via kernel or config);
* Interface went from down to up;
* Update in the link-params configuration.
Now also send ZEBRA_INTERFACE_LINK_PARAMS messages whenever a zclient
connects and sends a ZEBRA_INTERFACE_ADD request. Without this fix,
the client daemons don't receive interface link parameters if they
are configured in the zebra startup configuration.
Renato Westphal [Fri, 18 Jan 2019 18:06:00 +0000 (16:06 -0200)]
lib: fix checking of clients subscribed to receive default routes
In these two functions, we were using VRF_DEFAULT instead of the
VRF ID passed as a parameter when checking if the given client
subscribed to receive default routes or not. This prevented the
"default-originate" command from ospfd/isisd from working correctly
under specific circumstances.
Renato Westphal [Fri, 18 Jan 2019 18:06:00 +0000 (16:06 -0200)]
zebra: fix checking of clients subscribed to receive interface info
client->ifinfo is a VRF bitmap, hence we need to use
vrf_bitmap_check() to check if a client is subscribed to receive
interface information for a particular VRF. Just checking if
the client->ifinfo value is set will always succeed since it's
a pointer initialized by zserv_client_create(). With this fix,
we'll stop sending interface messages from all VRFs to all clients,
even those that didn't subscribe to it.
projects / mirror / frr.git / log