Donald Sharp [Wed, 28 Aug 2019 19:50:23 +0000 (15:50 -0400)]
tests: Modify docker build for local to have dev build
Allow a local build of a frr docker container to be built with
`--enable-dev-build`. This allows better decodes of symbols
which could be useful when you are trying to fix something
that is broken inside the docker container.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Wed, 28 Aug 2019 16:09:41 +0000 (12:09 -0400)]
lib: Stop arm crash on shutdown
Arm platforms are crashing in our topotests with this callstack;
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
[Current thread is 1 (Thread 0xffffabb591d0 (LWP 18947))]
(gdb) bt
file=file@entry=0xaaaadfed1e48 "lib/memory.c", line=line@entry=80,
function=function@entry=0xaaaadfed1db8 <__func__.10514> "mt_count_free") at lib/log.c:837
(gdb)
So we are crashing because we are attempting to free a mtype that has no allocations
associated with it.
I added this debug code:
@@ -227,7 +230,9 @@ static void rcu_bump(void)
struct rcu_next *rn;
rn = XMALLOC(MTYPE_RCU_NEXT, sizeof(*rn));
-
+ zlog_debug("RCU_BUMP");
+ mtype_dump(MTYPE_RCU_THREAD);
+ mtype_dump(MTYPE_RCU_NEXT);
/* note: each RCUA_NEXT item corresponds to exactly one seqno bump.
* This means we don't need to communicate which seqno is which
* RCUA_NEXT, since we really don't care.
and added a mtype_dump function:
+void mtype_dump(struct memtype *mt)
+{
+ zlog_debug("%s: %d", mt->name, (int)mt->n_alloc);
+}
I would have expected the output to be:
RCU_BUMP
RCU thread: 3
RCU sequence barrier: X
instead.
As a thought experiment I reduced the number of static memory types
to 1 in the file and the crash stopped happening.
I suspect we have a systematic error on arm in lib/memory.h
due to the asm code. I am going to leave that alone for the
moment ( and leave the crash issue open ), but see if we
can get this code change into the system so that our CI
system becomes happy again.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Tue, 27 Aug 2019 18:55:48 +0000 (14:55 -0400)]
*: Start process of possibly deprecating Solaris
The FRR community has run into an issue where keeping up our
CI system to work with solaris has become a fairly large burden.
We have also sent emails and asked around and have not found
anyone standing up saying that they are using Solaris.
Given the fact that we do not have any comprehensive testing
being done w/ solaris and the fact that we are getting a steady
stream of new features that will never work on solaris and
we cannot find anyone to say that they are using it. Let's
start the drawn out process of deprecating the code.
If in the mean-time someone comes forward with the fact that
they are using it we can then not deprecate it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Dinesh G Dutt [Tue, 27 Aug 2019 01:48:53 +0000 (01:48 +0000)]
bgpd: Eliminate all incorrect formulations of afi/safi in JSON
In a number of places, the JSON output had invalid key names for
AFI/SAFI. For example, the key name in JSON was "IPv4 Unicast" which
is invalid as a JSON Key name. Many JSON tools such as those used in
Ansible, jq etc. all fail to parse the output in these scenarios. The
valid name is ipv4Unicast. There's already a routine afi_safi_json()
defined to handle this change, but it was not consistently called.
The non-JSON version was called afi_safi_print() and it merely returned
the CLI version of the string, didn't print anything.
This patch deals with this issue by:
- Renaming afi_safi_print to get_afi_safi_str()
- get_afi_safi_str takes an additional param, for_json which if true
will return the JSON-valid string
- Renaming afi_safi_json to get_afi_safi_json_str()
- Creating a new routine get_afi_safi_vty_str() for printing to vty
- Consistently using get_afi_safi_str() with the appropriate for_json
value
Signed-off-by: Dinesh G Dutt <5016467+ddutt@users.noreply.github.com>
eva# show bgp ipv4 uni 4.4.4.4
BGP routing table entry for 4.4.4.4/32
Paths: (1 available, best #1, table default)
Advertised to non peer-group peers:
10.50.12.118
999 999 999 999
10.50.12.118 from 10.50.12.118 (10.50.12.118)
Origin incomplete, metric 0, valid, external, best (First path received)
Last update: Mon Aug 26 09:47:17 2019
eva# conf
eva(config)# route-map BLARBLE permit 10
eva(config-route-map)# no set as-path prepend last-as 3
eva(config-route-map)# end
eva# clear bgp ipv4 uni *
eva# show bgp ipv4 uni 4.4.4.4
BGP routing table entry for 4.4.4.4/32
Paths: (1 available, best #1, table default)
Advertised to non peer-group peers:
10.50.12.118
999
10.50.12.118 from 10.50.12.118 (10.50.12.118)
Origin incomplete, metric 0, valid, external, best (First path received)
Last update: Mon Aug 26 09:48:31 2019
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Dinesh G Dutt [Mon, 26 Aug 2019 12:38:28 +0000 (12:38 +0000)]
lib: Make if_lookup_by_index understand if VRF is backed by netns or not
FRR has two implementations of VRF, one backed by netns and the other by
the proper VRF implementation in the Linux kernel. In certain places, the
code assumes that a VRF is netns and so lookups fail. One example of this
is in IPv6 RA code. This causes functionality such as Unnumbered BGP to
fail. To fix this, this patch makes if_lookup_by_index handle the
behavior based on the backend, similar to if_get_by_index. For the two
places in if.c that were calling if_lookup_by_index to be specific to
the VRF, I renamed the existing code, if_lookup_by_ifindex and made it a
static function that is never exposed or called by any routine outside of
if.c.
Signed-off-by: Dinesh G Dutt <5016467+ddutt@users.noreply.github.com>
vdhingra [Mon, 12 Aug 2019 11:15:29 +0000 (04:15 -0700)]
bgpd : Ambiguous command: show bgp large-community-list 1
When user wants to dump individual large-community-list with the name
then bgp throws an error. It is due to command to dump the bgp RIB routes
having a particular large-community-list values. To segregate both the
commands this fix has added the detail keyword in the below command.
show bgp large-community-list <(1-500)|WORD> detail
The same code change is applicable for community-list also.
Donald Sharp [Fri, 23 Aug 2019 19:44:32 +0000 (15:44 -0400)]
bgpd: Allow shortened input for `show bgp l2vpn evpn route type e|p`
The `show bgp l2vpn evpn route type <es|prefix>` commands
only accepted 2 letters. You could not type `show bgp l2vpn evpn route type e`
or `show bgp l2vpn evpn route type p` although both are technically legal
since nothing overlaps with them.
Ticket: CM-25988 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
vdhingra [Fri, 23 Aug 2019 05:36:36 +0000 (22:36 -0700)]
zebra: Added a few more information in route_entry while dumping
re->nexthop_num and re->nexthop_active_num are calculated while rib
processing. Also It helps in encoding the ZAPI message.
It's good to dump these parameters also, when the system is in
abnormal state.
Renato Westphal [Thu, 22 Aug 2019 14:29:37 +0000 (11:29 -0300)]
isisd: add support for IPv6 BFD peers
Make isisd create BFD sessions over IPv6 when IS-IS is configured
for IPv6 operation only.
When IS-IS is enabled for both IPv4 and IPv6 on a given interface,
prefer creating a BFD session over IPv6 to avoid having two BFD
sessions protecting the same IS-IS adjacency.
Ashish Pant [Tue, 20 Aug 2019 04:21:59 +0000 (09:51 +0530)]
tests: Enhance execution logs in topojson
Signed-off-by: Ashish Pant <ashish12pant@gmail.com>
1. Add check if show running output is corrupted as frr-reload does
not return cause of failure, just the error codes.
2. Change logger level to debug for some extra information.
3. Modify logger messages for more clear information.
4. Print configuration commands to console instead of show running
5. Print show command output to console.
6. Move show running output within flag show_router_config.
7. Add retry decorator for retyring show commands.
Donald Sharp [Wed, 21 Aug 2019 15:44:48 +0000 (11:44 -0400)]
tests: Add a couple simple Null0 spelling tests
Add a bit of code to test different spelling of Null0 routes.
This was broken at some point in the past and with recent
changes is working again, but it would be nice to
know when this breaks again.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Renato Westphal [Wed, 7 Aug 2019 00:30:08 +0000 (21:30 -0300)]
lib: don't ignore stream errors in some zapi decode functions
Some other ZAPI decode functions still use void return values and
can't propagate stream errors to their callers. They need to be fixed
as well in the future.
Don Slice [Mon, 12 Aug 2019 19:02:39 +0000 (19:02 +0000)]
bgpd: make clear bgp * clear all peers in all afi/safis
Problem reported that "clear bgp *" only cleared ipv6 peers.
Changed the logic to clear all afi/safis of all peers in
that case. Also improved the operation of clearing
individual afi/safi using soft/in/out to do the right thing.
Ticket: CM-25887 Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Donald Sharp [Mon, 19 Aug 2019 14:25:40 +0000 (10:25 -0400)]
pbrd, sharpd, staticd: Add some color to sample configuration files
The sample configuration files for pbrd, sharpd and staticd
where all the same. Add some bit of color to help new people
get rolling on these three daemons.
Signed-off-by: Donald Sharp <sharpd@cumulusnetwork.com>
Donald Sharp [Mon, 19 Aug 2019 14:12:30 +0000 (10:12 -0400)]
*: Fix spelling errors pointed out by debian packaging
Debian packaging when run finds a bunch of spelling errors:
I: frr: spelling-error-in-binary usr/bin/vtysh occurences occurrences
I: frr: spelling-error-in-binary usr/lib/frr/bfdd Amount of times Number of times
I: frr: spelling-error-in-binary usr/lib/frr/bgpd occurences occurrences
I: frr: spelling-error-in-binary usr/lib/frr/bgpd recieved received
I: frr: spelling-error-in-binary usr/lib/frr/isisd betweeen between
I: frr: spelling-error-in-binary usr/lib/frr/ospf6d Infomation Information
I: frr: spelling-error-in-binary usr/lib/frr/ospfd missmatch mismatch
I: frr: spelling-error-in-binary usr/lib/frr/pimd bootsrap bootstrap
I: frr: spelling-error-in-binary usr/lib/frr/pimd Unknwon Unknown
I: frr: spelling-error-in-binary usr/lib/frr/zebra Requsted Requested
I: frr: spelling-error-in-binary usr/lib/frr/zebra uknown unknown
I: frr: spelling-error-in-binary usr/lib/x86_64-linux-gnu/frr/libfrr.so.0.0.0 overriden overridden
This commit fixes all of them except the bgp `recieved` issue due to
it being part of json output. That one will need to go through
a deprecation cycle.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
vivek [Mon, 19 Aug 2019 06:07:59 +0000 (23:07 -0700)]
bgpd: Ensure correct checks for EVPN route import
In a situation where a VRF has configured route targets for importing
EVPN routes, this configuration may exist prior to the VRF being
ready to have EVPN routes installed into it - e.g., still missing
the L3VNI configuration or associated interface information. Ensure
that this is taken into account during EVPN route import and unimport.
Without this fix, EVPN routes would end up being prematurely imported
into the VRF routing table and consequently installed as inactive
(because the nexthop information would be incorrect when BGP informs
zebra).
vivek [Mon, 19 Aug 2019 05:12:06 +0000 (22:12 -0700)]
bgpd: Fix nexthop reg for IPv4 route exchange using GUA IPv6 peering
In the case of IPv4 route exchange using GUA IPv6 peering, the route install
into the FIB involves mapping the immediate next hop to an IPv4 link-local
address and installing neighbor entries for this next hop address. To
accomplish the latter, IPv6 Router Advertisements are exchanged (the next hop
or peer must also have this enabled) and the RAs are dynamically initiated
based on next hop resolution.
However, in the case of a passive connection where the local system has not
initiated anything, no NHT entry is created for the peer, hence RAs were not
getting triggered. Address this by ensuring that a NHT entry is created even
in this situation. This is done at the time the connection becomes established
because the code has other assumptions that a NHT entry will be present only
for the "configured" peer. The API to create the entry ensures there are
no duplicates.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Juergen Werner [Tue, 13 Aug 2019 14:29:09 +0000 (16:29 +0200)]
zebra: Correct /32 addr del with broadcast set
Since we are now away from the dual use of the destination field, there
is no need to single out /32 addresses as broadcast. This was bugged
anyway, since the same /32 criteria was used for IPv6 addresses as well,
when `connected_check_ptp` is called in `connected_delete_ipv6`.
Fixes: 3053 Signed-off-by: Juergen Werner <juergen@opensourcerouting.org>
Juergen Werner [Sat, 10 Aug 2019 09:52:03 +0000 (11:52 +0200)]
zebra: Do not use connection dest for bcast
The `destination` field of the connection structure was used to store
the broadcast address, if the connection was not p2p. This multipurpose
is not very evident and the benefits over calculating the bcast address
on the fly minimal.
Signed-off-by: Juergen Werner <juergen@opensourcerouting.org>
Dinesh Dutt [Mon, 12 Aug 2019 13:20:18 +0000 (13:20 +0000)]
bgpd: Display the imported route information for EVPN routes
For IPv4/v6 unicast routes that have been imported from EVPN Prefix
routes, display the information about where the route has been imported
from allowing for easy tracing of how a FIB/RIB entry got populated.
Signed-off-by: Dinesh G Dutt <5016467+ddutt@users.noreply.github.com>
vdhingra [Wed, 14 Aug 2019 07:18:43 +0000 (00:18 -0700)]
zebra : zebra redistributing IPV4 link local Addresses inconsistently.
Create an interface with IP4 link local address 169.254.0.131/25.
In BGP enable the redistribute connected. Now Zebra will not send
the route corresponding to IPV4 link local address. Now made this
interface down and up. Zebra sends the route to BGP.
Zebra should not send this route to BGP.
This Fix would make the behaviour consistent and would not send the
routes corresponding to IPV4 Link local addresses.
Dinesh G Dutt [Tue, 13 Aug 2019 16:29:40 +0000 (16:29 +0000)]
zebra: Ensure master's ifname is known, even if slave comes up first
In if_netlink.c, when an interface structure, ifp, is first created,
its possible for the master to come up after the slave interface does.
This means, the slave interface has no way to display the master's ifname
in show outputs. To fix this, we need to allow creation by ifindex instead
of by ifname so that this issue is handled.
Signed-off-by: Dinesh G Dutt<5016467+ddutt@users.noreply.github.com>
Dinesh G Dutt [Tue, 13 Aug 2019 16:28:16 +0000 (16:28 +0000)]
zebra: Display master interface names, not ifindices
When displaying the master interface's information in "show interface",
the display is currently the ifindex of the master interface. Make it
display the name as well as that is more useful than the name.
Signed-off-by: Dinesh G Dutt<5016467+ddutt@users.noreply.github.com>
vdhingra [Tue, 13 Aug 2019 05:56:38 +0000 (22:56 -0700)]
zebra : blackhole_type was not set correctly in recursive routes
If there is a recursive route resolved over blackhole route, then
the resolved blackhole_type is not getting set correctly.
This fix updates the bh_type correctly for resursive routes.
bgpd: Optimizing route-map's processing of dependencies.
Say for eg., 256 prefix-list entries are pasted to VTYSH.
This results in BGP processing the events for several minutes.
BGPD starts a timer for 5 seconds when the first dependency configuraion
is received. On timer expiry, BGP process dependent route-maps.
After this processing, BGPD reads the configurations received in the
next 5 seconds and then re-processes the route-maps from the beginning.
This cyclic re-processing consumes time and CPU cycles.
Instead of starting a timer when the first configuration is received,
everytime a configuration is received, the existing timer is reset.
This would mean that all the configurations are read first before the timer
expires. This eliminates the cyclic re-processing.
bgpd: Large-communities CLI accepts configurations sans attributes.
BGP large-communities configuration CLI is successful even if
the command is configured without any attributes.
For ex., the below commands are successful.
1) "bgp large-community-list standard TEST permit"
2) "bgp large-community-list standard TEST deny"
The CLI definitions that allow these erroneous configurations need to be removed.
A race condition causes the failure.
The function "make_info()" sets the path info's peer to
bgp instance's "peer_self" which is created when BGP is first
configured and deleted only when BGP is brought down completely.
A race condition causes the bgp instances's "peer_self" to be
removed before the routes are being pulled off from the aggregate
address.
If the bgp instance's "peer_self" is NULL or, if BGP is being deleted,
the aggregate route must not be reinstalled.
bgpd: Standard large-communities CLI does not return error when it's configured with reg-ex.
The CLI to configure the standard format large-communities attribute
accepts regular expressions as well.
For ex., the below configuration is accepted.
"bgp large-community-list standard TEST permit 1:1 100:*"
The code to parse the large-communities does identify the configuration
as invalid however, error returned isn't processed.
The code has to be modified to handle the error.
Ameya Dharkar [Fri, 9 Aug 2019 22:21:27 +0000 (15:21 -0700)]
Zebra: Incorrect L3VNI for FPM rtmsg for EVPN RT-5 prefix
We used the vrf_id in the rtm_table field of the netlink rtmsg to fetch L3VNI.
But, now we program table_id to rtm_table field instead of vrf_id.
Thus, L3VNI fetched using rtm_table is incorrect.
Chirag Shah [Thu, 8 Aug 2019 17:43:49 +0000 (10:43 -0700)]
zebra: fix advertise svi ip as macip route
PR #3745 added EVPN feature to advertise individual
SVI-IPs as MAC-IP routes.
Fix a condition in zebra to send MAC and IP pair
to bgpd when the feature is enabled.
Testing Done:
Originator VTEP:
TORC11:~# ip -br addr show VxU-1002
VxU-1002 UP 45.0.2.2/24 2001:fee1:0:2::2/64
show bgp l2vpn evpn vni 1004
VNI: 1004 (known to the kernel)
Type: L2
Tenant-Vrf: default
RD: 27.0.0.11:3
Advertise-svi-macip : Yes
Import Route Target:
10:1004
Export Route Target:
10:1004
Remote vtep evpn route output for 45.0.4.2:
BGP routing table entry for 27.0.0.11:3:[2]:[0]:[48]:[00:02:00:00:00:2f]:[32]:[45.0.4.2]
Paths: (2 available, best #1)
Advertised to non peer-group peers:
MSP1(uplink-1) MSP2(uplink-2)
Route [2]:[0]:[48]:[00:02:00:00:00:2f]:[32]:[45.0.4.2] VNI 1004
64435 65546
36.0.0.11 from MSP1(uplink-1) (27.0.0.9)
Origin IGP, valid, external, bestpath-from-AS 64435, best (First path received)
Extended Community: RT:10:1004 ET:8
Last update: Thu Aug 8 18:09:13 2019
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Dinesh Dutt [Thu, 8 Aug 2019 02:58:18 +0000 (02:58 +0000)]
bgpd: Display received and advertised EVPN routes from neighbors
"show bgp l2vpn evpn neighbors <neighbor> [advertised-routes|routes]' did
not work due to various bugs. First, the command only accepted IPv4
addresses as valid neighbor ID, thereby rejecting unnumbered BGP and IPv6
neighbor address. Second, the SAFI was hardcoded to MPLS_VPN even though
we were passing the safi. Third, "all" made no sense in the command context
and to make the command uniform across all address families, I removed the
"all" keyword from the command.
Donald Sharp [Thu, 8 Aug 2019 01:45:02 +0000 (21:45 -0400)]
staticd: Fix blackhole routes being installed
When we are ready to install a route, we were treating
blackhole routes as something that should be nexthop tracked
which does not work as well as one would expect.
Additionally add some test code to show that this actually
fixes this issue.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
projects / mirror_frr.git / log