[ 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=155555
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=155030
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
s...@chittenden.org
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
