Date: Fri, 25 Mar 2011 18:26:46 -0700 From: Sean Chittenden <sean@chittenden.org> To: net@freebsd.org Subject: PR kern/155772 (&& maybe kern/155555)... Message-ID: <B8DBB967-2D5E-464B-816E-4B9B1A340677@chittenden.org>
next in thread | raw e-mail | index | archive | help
[ 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B8DBB967-2D5E-464B-816E-4B9B1A340677>