If the manager resides on the same host as ovs, the manager target will
be the loopback address. Then, if in-band is enabled on a bridge, the
in-band module will constantly checks the connection to the manager to
make sure the manager is reachable. However, the connection checking
implementation cannot identify the route for the loopback address and
will keep issuing the following warning:
|in_band|WARN|cannot find route for controller (127.0.0.1): No such
device or address.
To fix this, this commit makes ovs not consider manager with loopback
for in-band control at all, since the manager is always reachable
on the same host.
Signed-off-by: Alex Wang <al...@nicira.com>
---
vswitchd/bridge.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/vswitchd/bridge.c b/vswitchd/bridge.c
index ee96f38..fa30513 100644
--- a/vswitchd/bridge.c
+++ b/vswitchd/bridge.c
@@ -509,7 +509,8 @@ bridge_exit(void)
* should not be and in fact is not directly involved in that. But
* ovs-vswitchd needs to make sure that ovsdb-server can reach the managers, so
* it has to tell in-band control where the managers are to enable that.
- * (Thus, only managers connected in-band are collected.)
+ * (Thus, only managers connected in-band and with non-loopback addresses
+ * are collected.)
*/
static void
collect_in_band_managers(const struct ovsrec_open_vswitch *ovs_cfg,
@@ -545,9 +546,11 @@ collect_in_band_managers(const struct ovsrec_open_vswitch
*ovs_cfg,
struct sockaddr_in in;
} sa;
+ /* Ignore loopback. */
if (stream_parse_target_with_default_port(target, OVSDB_PORT,
&sa.ss)
- && sa.ss.ss_family == AF_INET) {
+ && sa.ss.ss_family == AF_INET
+ && sa.in.sin_addr.s_addr != htonl(INADDR_LOOPBACK)) {
managers[n_managers++] = sa.in;
}
}
--
1.7.9.5
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
