From owner-freebsd-net@FreeBSD.ORG Sat Mar 26 01:42:31 2011
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
by hub.freebsd.org (Postfix) with ESMTP id D5454106564A
for <net@freebsd.org>; Sat, 26 Mar 2011 01:42:31 +0000 (UTC)
(envelope-from sean@chittenden.org)
Received: from mail01.lax1.stackjet.com (mon01.lax1.stackjet.com
[174.136.104.178])
by mx1.freebsd.org (Postfix) with ESMTP id A71078FC17
for <net@freebsd.org>; Sat, 26 Mar 2011 01:42:31 +0000 (UTC)
Received: from somehost-30.sv2.equinix.net (unknown [64.191.195.30])
(using TLSv1 with cipher AES128-SHA (128/128 bits))
(No client certificate requested)
(Authenticated sender: sean@chittenden.org)
by mail01.lax1.stackjet.com (Postfix) with ESMTPSA id 5682B3E88D8
for <net@freebsd.org>; Fri, 25 Mar 2011 18:26:47 -0700 (PDT)
From: Sean Chittenden <sean@chittenden.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Fri, 25 Mar 2011 18:26:46 -0700
Message-Id: <B8DBB967-2D5E-464B-816E-4B9B1A340677@chittenden.org>
To: net@freebsd.org
Mime-Version: 1.0 (Apple Message framework v1082)
X-Mailer: Apple Mail (2.1082)
Cc:
Subject: PR kern/155772 (&& maybe kern/155555)...
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Mar 2011 01:42:31 -0000
[ Please keep me CC'ed ]
Hello. It looks like I'm running in to kern/155772. The ticket was =
sparse on details so here's how to reproduce the problem:
I have two routers using openospfd && bgpd:
br1 <-- igb0 -> br2
| |
| igb1 | igb1
| |
----+--------------+----
10.1.1.0/24
br1: ifconfig igb1 inet 10.1.1.2 netmask 255.255.255.0
br2: ifconfig igb1 inet 10.1.1.3 netmask 255.255.255.0
When I restart ospfd on br2 (not reload), *br1* looses its connectivity =
to all directly connected routes (both igb0 and igb1). If I perform a =
`route -n get 10.1.1.10` on br1, route(8) returns the right information =
for igb1, however when I ping 10.1.1.10 from br1, I get a network not =
reachable message. `ifconfig igb1` returns the right information as =
well. If I re-add the IP address via `ifconfig igb1 inet 10.1.1.2 =
netmask 255.255.255.255` I am able to reach the 10.1.1.0/24 network. =
It's like the FIB information is being removed for directly connected =
routes when ospfd updates br1's FIB. I've actually observed the same =
behavior when retracting statically connected routes via openbgpd as =
well (while attempting to trace the root of this problem, I configured =
an iBGP session to use a "next-hop self" rule and observed an identical =
behavior, same with quagga too).
I was thinking this was related to kern/155555 but I don't think that's =
the direct problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=3D155555
If anyone has patches or ideas, let me know. I have plenty of details if =
anyone's interested, but this seems so easy to reproduce or like a =
glaring regression. It feels very much like a refcount for routes isn't =
being incremented along the way or that some piece of logic is removing =
all matching routes, not just the routes learned from a routing =
protocol.
On a similar, but unrelated note of carp(4), I ran in to the problem =
described in the following post during the initial setup of these two =
routers:
http://lists.freebsd.org/pipermail/freebsd-net/2011-March/028349.html
This happened because br2's default route was pointing to br1, br1 was =
receiving its own carp packets while br2 was forwarding them back. =
Recompiling with MROUTING and enabling igmpproxy(8) seemed to fix the =
problem.
Thanks in advance. -sc
PS This one also bit me during turn up: =
http://www.freebsd.org/cgi/query-pr.cgi?pr=3D155030
PPS And, if you had a downstream hosts that have pf(4) enabled and had =
their default route set to 10.1.1.2, once you changed the default route =
to 10.1.1.1 or 10.1.1.3, all of the hosts that had pf(4) on them had to =
have their firewall rules reloaded (e.g. /etc/rc.d/pf reload) to reflect =
this changed default route. In previous 7.X, pf(4) picked up this change =
without needing to reload the rules.
--
Sean Chittenden
sean@chittenden.org