Decrease the initialization FSM timeout.

The previous value of 180 was just too long. If a neighbor get stuck in
the initialization FSM for more than 15 seconds, then there's certainly
something wrong and the session should be dropped.

A potential case of a neighbor getting stuck in the initialization
FSM is when both the local and the remote LSRs disable the LDPv4 GTSM
negotiation and there's a mismatch in their GTSM configuration (one is
enabled for GTSM while the other is not).

In this case, a smaller timeout allows for a quicker recovery of the
session when the configuration is fixed on either side.

diff --git a/usr.sbin/ldpd/ldp.h b/usr.sbin/ldpd/ldp.h
index 242452d..a6442ed 100644 (file)
--- a/usr.sbin/ldpd/ldp.h
+++ b/usr.sbin/ldpd/ldp.h
@@ -1,4 +1,4 @@
-/*     $OpenBSD: ldp.h,v 1.31 2016/07/01 23:18:24 renato Exp $ */
+/*     $OpenBSD: ldp.h,v 1.32 2016/07/01 23:22:42 renato Exp $ */
 
 /*
  * Copyright (c) 2013, 2016 Renato Westphal <renato@openbsd.org>
@@ -44,6 +44,7 @@
 #define MIN_KEEPALIVE          3
 #define MAX_KEEPALIVE          0xffff
 #define KEEPALIVE_PER_PERIOD   3
+#define INIT_FSM_TIMEOUT       15
 
 #define        DEFAULT_HELLO_INTERVAL  5
 #define        MIN_HELLO_INTERVAL      1

diff --git a/usr.sbin/ldpd/neighbor.c b/usr.sbin/ldpd/neighbor.c
index bf62c0d..ef50fa8 100644 (file)
--- a/usr.sbin/ldpd/neighbor.c
+++ b/usr.sbin/ldpd/neighbor.c
@@ -1,4 +1,4 @@
-/*     $OpenBSD: neighbor.c,v 1.75 2016/07/01 23:14:31 renato Exp $ */
+/*     $OpenBSD: neighbor.c,v 1.76 2016/07/01 23:22:42 renato Exp $ */
 
 /*
  * Copyright (c) 2013, 2016 Renato Westphal <renato@openbsd.org>
@@ -459,7 +459,7 @@ nbr_start_itimeout(struct nbr *nbr)
        struct timeval   tv;
 
        timerclear(&tv);
-       tv.tv_sec = DEFAULT_KEEPALIVE;
+       tv.tv_sec = INIT_FSM_TIMEOUT;
        if (evtimer_add(&nbr->init_timeout, &tv) == -1)
                fatal(__func__);
 }