Disable Bridge Loop Detection?

[Jonathan Feally]

I don't see why do you have 2 FreeBSD Boxes running as bridges. The only 
reason I could possibly imagine, is that you are using IPFW or IPFilter 
to do some packet filtering.

Now with vrrp, each router would have a unique IP and only one of the 
routers would have the shared IP at any given time using the shared vrrp 
mac address.
Your problem lies in Layer 2 packets - where vrrp functions. A 
bridge/switch is a layer 2 device that only passes traffic to the ports 
that need the traffic and nothing more. The vrrp advertisements will be 
from the shared MAC to ff:ff:ff:ff:ff:ff. with the IP src being the 
sending router and the IP dst being a multicast address. Now when the 
change from router 1 to router 2 takes place, router 1 will go back to 
it's original mac and router 2 will get the shared mac and start sending 
advertisements. So now from your picture, Bridge #2 would see that the 
vrrp mac is coming from the other side, thus causing a loop to be detected.

You're best solution is to remove one of the bridges, and add a cheap 
10/100 hub and connect like this:

??????????????????????????   Internet Connection
         |                        |
+-----------+   +-----------+
|  router #1   |    |  router #2  |      Internet Connectivity  Routers 
on .2 and .3 with .1 as the shared IP
+-----------+   +-----------+
         |                        |
+-------------------------+    This will solve your bridge seeing a loop 
by putting all vrrp traffic on only 1 side.
|   $10-$15 10/100 Hub    |    You shouldn't see any major network 
performance hit from using a hub here.
+-------------------------+   .The only way you could possibly see a 
network performance hit, would be if you had a huge pipe.
         |
      NIC A
         |
+------------------+  
|  FreeBSD Bridge  |   IPFW or IPFilter At this point - FreeBSD box on .4
+------------------+
          |
     NIC B
          |
+-------------+   +------------+
|   Switch #1   |-x-|  Switch #2   |   Hosts on the network 
63.208.196.0/25 - Switches on .5 and .6 - if possible
+-------------+   +------------+
  |   |   |    |   |  |        |  |  |  | |   |   |
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
Workstations and Servers        Machines on .10-.126 or whatever


Tim Wilde wrote:

>I'm looking for a way to disable the loop detection in the bridging code
>in FreeBSD 4.x - I'd prefer a sysctl, but I haven't been able to find one.
>Any suggestions for how to do so would be appreciated.
>
>In case anyone's wondering why I'm looking for such a thing, my problem is
>with the following topology:
>
> +----------+       +----------+
> | router 1 |       | router 2 |
> +----------+       +----------+
>      |                  |
> 63.208.196.1/25    63.208.196.2/25
>      |                  |
> +---------------+  +---------------+
> | FBSD bridge 1 |  | FBSD bridge 2 |
> +---------------+  +---------------+
>      |                  |
> +----------+       +----------+
> | switch 1 |-------| switch 2 |
> +----------+       +----------+
>      |                  |
>  various servers, 63.208.196.0/25
>
>The two routers run VRRP for redundancy, with a shared MAC address.
>Occasionally, router2 is failing to receive packets from router1 (for
>reasons we're looking into), and decides it should become the master,
>taking over the 63.208.196.1 IP with the shared MAC.  Now my two bridges
>both see that same MAC address on both of their interfaces, and the loop
>detection kicks in.  This cuts out the various links (and they fight back
>and forth cutting off - it's not pretty) with the end result of router2
>NEVER being able to get the next VRRP packet from router1 (by necessity
>they have to communicate for failover across the bridges + switches;
>otherwise they wouldn't be able to detect failures internal to that
>network).  We have to manually down the interface on router2, let things
>calm down on the FreeBSD boxen, and then bring it back up (it starts in
>backup mode, and waits at least 30 seconds, plenty of time to hear from
>router1, before it will take control again).
>
>Thanks,
>Tim
>
>  
>