December 2016 - dev - lists.frrouting.org

Re: [cmaster-next] Bug in zebra_mpls
by Renato Westphal 13 Dec '16

13 Dec '16

On Mon, Dec 12, 2016 at 11:18 AM, Bingen Eguzkitza <bingen(a)voltanet.io> wrote: > Adding Renato too, as he might be interested in. > > On Mon, Dec 12, 2016 at 2:16 PM, Bingen Eguzkitza <bingen(a)voltanet.io> > wrote: >> >> Hi, >> >> Fredi and Marc here found a bug that was causing Zebra to segfault. Find >> attached a patch for it. I'm ok with this patch in the sense that it's an useful safeguard to have. But I can't see how this was causing a segfault to you. NHLFE entries are never removed directly. Instead of that, we always set the NHLFE_FLAG_DELETED flag and call lsp_processq_add(). Then the Quagga's workqueue guarantees that lsp_process() is called before lsp_processq_del(), which is where nhlfe_del() is called. With that said, it's impossible to have an invalid 'lsp->best_nhlfe' pointer in lsp_process(). There's one other case where nhlfe_del() is called directly which is when the NHLFE_FLAG_INSTALLED flag is not set. But in this case the NHLFE entry will never be best NHLFE entry from the corresponding LSP. Finally, the lines introduced by your patch are not consistent in style with the rest of code (GNU style). Please resubmit a new version with this fixed. -- Renato Westphal

2 2

[cmaster-next] Fork Naming Survey
by Martin Winter 13 Dec '16

13 Dec '16

We have a Survey for the Fork name online with all the proposed names. Please vote on what you like or don’t like. https://goo.gl/forms/DlQvuYD4dB9wSWXs1 Everyone is _ENCOURAGED_ to cast their vote. Closing date of the Survey is 1hr before the Technical Meeting on Dec 13. (The meeting organized by Donald) (I’ll use that hour to collect the results and get the details together for the Tuesday Technical Meeting and we can have then a short discussion on how to get to the final name) - Martin

3 4

[cmaster-next] EVPN - notes on the Cumulus implementation
by Vivek Venkatraman 13 Dec '16

13 Dec '16

Here is some information on the Cumulus implementation. We can discuss further in tomorrow's meeting and/or subsequent ones. Functional description: The Cumulus implementation of EVPN is focused on EVPN as the control plane for VxLAN, though it is certainly feasible to extend it to support other encapsulations - e.g., MPLS. It is also clearly a work-in-progress. The implementation is focused on Linux as the network OS; there will be work needed to extend it for FreeBSD or provide the FPM-type interface. The current state of the implementation (end November 2016) allows for MAC learning and exchange but not for MAC+IP. The latter requires some enhancements to the Linux kernel's "ARP proxy" (ARP suppression) capabilities for VxLAN, and this is currently in the works. A precursor to MAC exchange is the exchange of VxLAN topology. This will build the mapping of VNIs to remote VTEPs and is required for handling BUM traffic through ingress replication. The exchange of this topology happens in BGP through the EVPN type-3 route. Currently, this is not configurable (i.e., these routes will always get exchanged). Additional options need to be added to disable this exchange (and hence, possibly, drop BUM traffic), attach to a multicast group or have the ability to go to a service or replicator node. Remote VTEPs learnt by BGP and informed to zebra will result in the "flood list" being setup - by installing the appropriate neighbor entry in the MAC FDB. MACs are exchanged using EVPN type-2 route. Local MACs get associated to the appropriate VNI. Remote MACs learnt by BGP and informed to zebra will be installed in the kernel MAC FDB. Some of the other aspects still in the works are the BGP encapsulation attribute (RFC 5512 - basic code already there in branch from Lou), the PMSI attribute (RFC 6514) and MAC mobility extended community (RFC 7432). All BGP protocol exchanges are as per RFC 7432 and draft-ietf-bess-evpn-overlay. Handling of access device dual homing (i.e., vPC, MLAG etc. in vendor speak) does not currently intend to use the EVPN type-4 route or EVPN type-1 route and related procedures. Instead, it will rely on the corresponding VTEPs using an "anycast IP" as their tunnel end point. This is in accordance with current industry practice (i.e., Cisco and Arista's approach). Work on L3 multi-tenancy (i.e., Inter-VxLAN routing) is at an early stage. This is where EVPN type-5 routes will be needed along with associating tenants to corresponding L3 VRFs, support for the Router MAC extended community etc. Provisioning/Management: As with other vendor implementations, there is no explicit configuration of a "MAC VRF" - the VNI defines the L2 domain and is the MAC VRF. VNIs (VxLAN interfaces), association of these to a bridge and mapping of access (VLAN) interfaces to the bridge are all supported (done) through existing Linux interfaces i.e., iproute2 or ifupdown2. There are no new Quagga commands to create or update these. The only essential pieces of Quagga configuration needed to activate EVPN (for the current and near-term functionality) are: a) enable EVPN - the current commands for this is "advertise-vni" b) activate EVPN address family for the remote VTEPs (or appropriate BGP peers, if peering is hop-by-hop) router bgp <as> address-family evpn advertise-vni neighbor <nbr> activate With the above configuration, VNIs known to the system will get associated with automatic RDs and RTs. The RDs are formed as "RouterID:VNI" and the RTs (import and export) are formed using "AS:VNI". Configuration options are provided to specify a different RD and/or RT value for a VNI. Whichever parameter that is not user-configured will be auto-derived. The VNI will of course be "active" only when it is known to the system (i.e., provisioned through existing Linux interface). router bgp <as> address-family evpn advertise-vni neighbor <nbr> activate vni <vni> rd <value> route-target import <value> ... route-target export <value> The main vtysh commands currently available to manage/monitor EVPN operation are: show evpn vni show evpn vni <vni> mac show bgp evpn summary show bgp evpn route show bgp evpn route rd <rd> Design description: zebra provides the kernel interface (through netlink) and maintains the VNI information and the MAC table per VNI. It should be considered later if these need to move into a "l2d"; this is best taken up for consideration, if at all, in conjunction with a "vrfd" and an "ifd" so that zebra effectively becomes "rtmd". The VNI hash table is populated with local VNIs which are learnt through existing netlink "link" notifications. The hash table also contains the remote VTEPs which are updated by BGP. Linux currently only supports an IPv4 address as the VTEP IP, so while the code has support for IPv6 address as a VTEP, it is incomplete. To be able to associate local MACs to the correct VNI (if they are associated with a VNI), zebra needs to understand bridges and bridge members and the VLAN to VNI mapping. These are built by listening mostly to existing netlink "link" notifications, however, some notifications related to the AF_BRIDGE family also need to be processed. The "L2" information for an interface is maintained in a structure linked off 'struct zebra_if'. The VNI hash table contains the MAC table corresponding to the VNI. This includes local MACs learnt from netlink "neighbor" notifications (AF_BRIDGE) as well as remote MACs updated by BGP. The remote MACs result in MAC FDB entries being installed in the kernel. When this is extended for MAC+IP, the IP information will result in creation of ARP "suppression" entries in the kernel. BGP also has a VNI hash table that it builds through interaction with zebra. Currently, there is no per-VNI routing table. Instead, EVPN routes (both local and remote) are only maintained in the main routing table where they are organized using a hierarchical radix tree in the same fashion as L3VPN routes and ENCAP routes. This is likely to need change in order to handle various scenarios. The change envisioned is that local EVPN routes will be only present in the per-VNI routing table from where they will be advertised to EVPN peers; remote (i.e., learnt) EVPN routes will be present in the global EVPN routing table from where they will be "imported" into one or more VNI routing tables; the import can/will be done as a separate thread. Thanks, Vivek

3 2

[cmaster-next] [PATCH] lib: Partial Revert of 4ecc09d and modify zclient connect behavior
by Donald Sharp 12 Dec '16

12 Dec '16

Commit 43cc09d has been shown to cause several issues with clients connecting. Partial revert, since I wanted to keep the debug logs added for that commit, as well remove the piece of code that stops attempting to connect to zebra. If we've failed a bunch of times, there is nothing wrong with continuing to do so once every 60 seconds. I've debug guarded the connect failure for those people running bgp without zebra. Signed-off-by: Donald Sharp <sharpd(a)cumulusnetworks.com> --- lib/zclient.c | 28 +++++++++------------------- 1 file changed, 9 insertions(+), 19 deletions(-) diff --git a/lib/zclient.c b/lib/zclient.c index 894e0d1..440de36 100644 --- a/lib/zclient.c +++ b/lib/zclient.c @@ -216,7 +216,9 @@ zclient_socket(void) ret = connect (sock, (struct sockaddr *) &serv, sizeof (serv)); if (ret < 0) { - zlog_warn ("%s connect failure: %d", __PRETTY_FUNCTION__, errno); + if (zclient_debug) + zlog_warn ("%s connect failure: %d(%s)", __PRETTY_FUNCTION__, + errno, safe_strerror (errno)); close (sock); return -1; } @@ -252,7 +254,9 @@ zclient_socket_un (const char *path) ret = connect (sock, (struct sockaddr *) &addr, len); if (ret < 0) { - zlog_warn ("%s connect failure: %d", __PRETTY_FUNCTION__, errno); + if (zclient_debug) + zlog_warn ("%s connect failure: %d(%s)", __PRETTY_FUNCTION__, + errno, safe_strerror (errno)); close (sock); return -1; } @@ -572,23 +576,11 @@ zclient_start (struct zclient *zclient) if (zclient->t_connect) return 0; - /* - * If we fail to connect to the socket on initialization, - * Let's wait a second and see if we can reconnect. - * Cause if we don't connect, we never attempt to - * reconnect. On startup if zebra is slow we - * can get into this situation. - */ - while (zclient_socket_connect(zclient) < 0 && zclient->fail < 5) + if (zclient_socket_connect(zclient) < 0) { if (zclient_debug) zlog_debug ("zclient connection fail"); zclient->fail++; - sleep (1); - } - - if (zclient->sock < 0) - { zclient_event (ZCLIENT_CONNECT, zclient); return -1; } @@ -1727,11 +1719,9 @@ zclient_event (enum event event, struct zclient *zclient) thread_add_event (zclient->master, zclient_connect, zclient, 0); break; case ZCLIENT_CONNECT: - if (zclient->fail >= 10) - return; if (zclient_debug) - zlog_debug ("zclient connect schedule interval is %d", - zclient->fail < 3 ? 10 : 60); + zlog_debug ("zclient connect failures: %d schedule interval is now %d", + zclient->fail, zclient->fail < 3 ? 10 : 60); if (! zclient->t_connect) zclient->t_connect = thread_add_timer (zclient->master, zclient_connect, zclient, -- 2.5.5

2 1

[cmaster-next] Latest RFC Compliance Results online
by Martin Winter 12 Dec '16

12 Dec '16

Latest results are online at https://drive.google.com/drive/folders/0B8W_T0dxQfwxeVRXdlNEb0I3NTQ?usp=sha… I’ve added results for FreeBSD 10.2 as well, but there is at least one major bug affecting FreeBSD (Issue #14). If anyone needs/wants detail on any result, then let me know. - Martin

1 0

[cmaster-next] Fwd: Bug in zebra_mpls
by Donald Sharp 12 Dec '16

12 Dec '16

---------- Forwarded message ---------- From: Bingen Eguzkitza <bingen(a)voltanet.io> Date: Mon, Dec 12, 2016 at 8:16 AM Subject: Bug in zebra_mpls To: Donald Sharp <sharpd(a)cumulusnetworks.com> Cc: Fredi Raspall <fredi(a)voltanet.io>, Marc Sune <marc(a)voltanet.io>, David Lamparter <david(a)opensourcerouting.org> Hi, Fredi and Marc here found a bug that was causing Zebra to segfault. Find attached a patch for it. ßingen.

1 0

[cmaster-next] [PATCH] quagga: Convert ldpd to be built by default
by Donald Sharp 12 Dec '16

12 Dec '16

(cherry picked from commit a67ce7192143de7de0741af3d0b4f72ee57c7ffd) --- configure.ac | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/configure.ac b/configure.ac index 7e751cd..128300c 100755 --- a/configure.ac +++ b/configure.ac @@ -1157,11 +1157,11 @@ else fi AM_CONDITIONAL(OSPFD, test "x$OSPFD" = "xospfd") -if test "${enable_ldpd}" = "yes";then +if test "${enable_ldpd}" = "no";then + LDPD="" +else LDPD="ldpd" AC_DEFINE(HAVE_LDPD, 1, ldpd) -else - LDPD="" fi AM_CONDITIONAL(LDPD, test "x$LDPD" = "xldpd") -- 2.9.3

4 4

[cmaster-next] [PATCH] lib: Partial Revert of 4ecc09d and modify zclient connect behavior
by Donald Sharp 12 Dec '16

12 Dec '16

Commit 43cc09d has been shown to cause several issues with clients connecting. Partial revert, since I wanted to keep the debug logs added for that commit, as well remove the piece of code that stops attempting to connect to zebra. If we've failed a bunch of times, there is nothing wrong with continuing to do so once every 60 seconds. I've debug guarded the connect failure for those people running bgp without zebra. Signed-off-by: Donald Sharp <sharpd(a)cumulusnetworks.com> --- lib/zclient.c | 25 ++++++------------------- 1 file changed, 6 insertions(+), 19 deletions(-) diff --git a/lib/zclient.c b/lib/zclient.c index 894e0d1..c8a8d58 100644 --- a/lib/zclient.c +++ b/lib/zclient.c @@ -216,7 +216,7 @@ zclient_socket(void) ret = connect (sock, (struct sockaddr *) &serv, sizeof (serv)); if (ret < 0) { - zlog_warn ("%s connect failure: %d", __PRETTY_FUNCTION__, errno); + zlog_warn ("%s connect failure: %d(%s)", __PRETTY_FUNCTION__, errno, safe_strerror); close (sock); return -1; } @@ -252,7 +252,8 @@ zclient_socket_un (const char *path) ret = connect (sock, (struct sockaddr *) &addr, len); if (ret < 0) { - zlog_warn ("%s connect failure: %d", __PRETTY_FUNCTION__, errno); + if (zclient_debug) + zlog_warn ("%s connect failure: %d", __PRETTY_FUNCTION__, errno); close (sock); return -1; } @@ -572,23 +573,11 @@ zclient_start (struct zclient *zclient) if (zclient->t_connect) return 0; - /* - * If we fail to connect to the socket on initialization, - * Let's wait a second and see if we can reconnect. - * Cause if we don't connect, we never attempt to - * reconnect. On startup if zebra is slow we - * can get into this situation. - */ - while (zclient_socket_connect(zclient) < 0 && zclient->fail < 5) + if (zclient_socket_connect(zclient) < 0) { if (zclient_debug) zlog_debug ("zclient connection fail"); zclient->fail++; - sleep (1); - } - - if (zclient->sock < 0) - { zclient_event (ZCLIENT_CONNECT, zclient); return -1; } @@ -1727,11 +1716,9 @@ zclient_event (enum event event, struct zclient *zclient) thread_add_event (zclient->master, zclient_connect, zclient, 0); break; case ZCLIENT_CONNECT: - if (zclient->fail >= 10) - return; if (zclient_debug) - zlog_debug ("zclient connect schedule interval is %d", - zclient->fail < 3 ? 10 : 60); + zlog_debug ("zclient connect failures: %d schedule interval is now %d", + zclient->fail, zclient->fail < 3 ? 10 : 60); if (! zclient->t_connect) zclient->t_connect = thread_add_timer (zclient->master, zclient_connect, zclient, -- 2.5.5

2 1

[cmaster-next] VTYSH behavior change and extract.pl elimination
by Quentin Young 09 Dec '16

09 Dec '16

Folks, I've been doing some hacking on vtysh in an effort to clean it up and fix some obscure bugs and less-than-sane interactions with daemons. Initially my efforts were focused on getting vtysh to automatically update its vty->node when a daemon node changes instead of needing a manual DEFUN override for every such daemon command. I have this working; after executing a command, the daemon side of the vty returns what node it is in in addition to the command status code and any output, which vtysh uses to update its own node. This in contrast to attempting to synchronize shared state over the life of a vtysh session without actually communicating said state. That said, I think vtysh could use some more work on a slightly larger scale. In my opinion extract.pl is fragile and error-prone. For example, any command definitions outside the source files it looks in (such as the default commands installed by lib/command.c) are not picked up and thus need to be manually replicated in vtysh. Additionally anytime new submodes are added, one has to remember to update extract.pl. And there are quite a few edge cases that vtysh has to handle that ain't pretty. I propose to change vtysh's behavior such that it no longer needs compile-time knowledge of daemon CLI. Instead it should ask each daemon for its CLI at runtime whenever needed, for example when a user types '?' or hits tab. This has several benefits: - extract.pl can go away since vtysh no longer needs to know about daemon cli, and just implements CLI specific to itself - vtysh binary becomes ~93% smaller - problem of keeping vtysh in sync with daemons becomes trivial - daemons gain the ability to choose what CLI they expose - saves confusion caused by vtysh silently accepting CLI for which the appropriate daemon is not running - CLI for daemons which are not running is not shown How to deal with this last point is probably the most important thing to discuss because that is the change the user will see. Since vtysh will no longer have foreknowledge of all CLI, it won't be able to distinguish between a bogus command and a command that's valid but for which the daemon is not running. I think this is an easy one to solve; we can just change % Unknown command to something like, for example, % Unknown command (or daemon not running). As mentioned above I see this as a benefit since it will prevent users getting confused by vtysh silently accepting CLI for stopped daemons. Feedback welcome. Quentin

3 2

[cmaster-next] stable/2.0 / initial delay before BGP availability through vty
by Philippe Guibert 09 Dec '16

09 Dec '16

Hi Donald, I have 2 questions/remarks. 1) Is there any specific reason why having kept the delay just after starting BGP daemon. Even with disabling zebra in configure, it takes quite some time. The root cause is related to: lib: Allow zclient do-over of connect on initial attempt Is there any reason to keep the mecanism like that ? Side effect of this is if you just execute bgp daemon and expect it to be available for configuration, either from vty ( or in a near-future basis capnproto), then the locked thread mecanism makes that it is not possible to immediately configure daemon. I would revert the commit. No ? 2) About this trace BGP: SLOW THREAD: task zclient_connect As this trace may happen more than once, is it necessary to add by default that I would put a conditionate to that trace. Regards, Philippe =================================== /sbin/bgpd 2016/12/08 17:33:55 BGP: BGPd 2.0-rc0 starting: vty@2605, bgp@<all>:179 2016/12/08 17:33:55 BGP: zclient_socket_un connect failure: 2 2016/12/08 17:33:56 BGP: zclient_socket_un connect failure: 2 2016/12/08 17:33:57 BGP: zclient_socket_un connect failure: 2 2016/12/08 17:33:58 BGP: zclient_socket_un connect failure: 2 2016/12/08 17:33:59 BGP: zclient_socket_un connect failure: 2 2016/12/08 17:34:00 BGP: zclient_socket_un connect failure: 2 2016/12/08 17:34:00 BGP: SLOW THREAD: task zclient_connect (7fa0e93c0cbc) ran for 5002ms (cpu time 0ms) 2016/12/08 17:34:00 BGP: zclient_socket_un connect failure: 2 2016/12/08 17:34:01 BGP: zclient_socket_un connect failure: 2 2016/12/08 17:34:02 BGP: zclient_socket_un connect failure: 2 2016/12/08 17:34:03 BGP: zclient_socket_un connect failure: 2 2016/12/08 17:34:04 BGP: zclient_socket_un connect failure: 2 2016/12/08 17:34:05 BGP: zclient_socket_un connect failure: 2 2016/12/08 17:34:05 BGP: SLOW THREAD: task zclient_connect (7fa0e93c0cbc) ran for 5000ms (cpu time 0ms) => Just at this point, VTY access OK

2 1