PR kern/155772 (&& maybe kern/155555)...

[Sean Chittenden]

[ 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
sean at chittenden.org