Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 26 Feb 2008 23:23:07 +0700
From:      Eugene Grosbein <eugen@kuzbass.ru>
To:        Boris Kochergin <spawk@acm.poly.edu>
Cc:        freebsd-net@freebsd.org
Subject:   Re: if_gif/if_bridge problem
Message-ID:  <20080226162307.GA80931@svzserv.kemerovo.su>
In-Reply-To: <47C428EC.3090909@acm.poly.edu>
References:  <47C428EC.3090909@acm.poly.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Feb 26, 2008 at 09:57:48AM -0500, Boris Kochergin wrote:

> bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 
> 1500
>        ether 3e:7f:e8:ef:f6:a4
>        inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
>        id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
>        maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
>        root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
>        member: gif6 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>

[skip]

> So, the tunnels and bridges appear to be sending the traffic around 
> properly, but the concentrator machine isn't replying to ARP requests 
> for its bridge0 interface's IP. This is where I'm stuck. Any help is 
> appreciated.

The problem is that if_bridge(4) won't work this way - with only one gif-member
without patching. I've faced this recently and debugged it in detail.
Then I've produced a patch and now I run it over a month in production
without a problem:

ftp://www.kuzbass.ru/pub/freebsd/lagg-0.1.tgz

Description inside, in Russian. In short: if_gif(4) no more kills
ethernet frames returned by if_bridge(4) as designated for upper levels
of TCP/IP stack but really passes them there. If the patched system
does not have EtherIP-tunnels then the patch affects nothing,
so it's safe to apply it. Also, you need not to reboot the system
if you load if_gif/if_bridge as modules, just rebuld and reload these.

The patch applies to all of 6.2, 6.3-PRERELEASE and 7.0-PRERELEASE,
and works (tested).

My task was a bit more complex so the patch touches if_lagg(4) too
but you need not use lagg(4) if you do not need it. The patch just
contains the solution for your problem too.

You can read detailed discussion in Russian there:
http://groups.google.com/group/fido7.ru.unix.bsd/browse_thread/thread/d6787b865515a66a/488d738afc265b19

Eugene Grosbein



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080226162307.GA80931>