FYI,
it is a good way to test bridge(4) and STP.
# ping 10.1.1.2
works fine in the following setup as rstp blocks bridge1/pair1:
bridge0: flags=41<UP,RUNNING>
groups: bridge
priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp
designated: id fe:e1:ba:d0:9d:91 priority 32768
pair0 flags=bb<LEARNING,DISCOVER,STP,EDGE,AUTOEDGE,AUTOPTP>
port 6 ifpriority 128 ifcost 55 forwarding role designated
pair2 flags=bb<LEARNING,DISCOVER,STP,EDGE,AUTOEDGE,AUTOPTP>
port 9 ifpriority 128 ifcost 55 forwarding role designated
bridge1: flags=41<UP,RUNNING>
groups: bridge
priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp
designated: id fe:e1:ba:d0:9d:91 priority 32768
pair1 flags=ab<LEARNING,DISCOVER,STP,AUTOEDGE,AUTOPTP>
port 7 ifpriority 128 ifcost 55 discarding role alternate
pair3 flags=ab<LEARNING,DISCOVER,STP,AUTOEDGE,AUTOPTP>
port 10 ifpriority 128 ifcost 55 forwarding role root
pair0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
lladdr fe:e1:ba:d0:9d:91
priority: 0
patch: pair1
groups: pair
media: Ethernet autoselect
status: active
inet 10.1.1.1 netmask 0xffffff00 broadcast 10.1.1.255
pair1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> rdomain 1 mtu
1500
lladdr fe:e1:ba:d1:93:7b
priority: 0
patch: pair0
groups: pair
media: Ethernet autoselect
status: active
inet 10.1.1.2 netmask 0xffffff00 broadcast 10.1.1.255
pair2: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
lladdr fe:e1:ba:d2:93:8a
priority: 0
patch: pair3
groups: pair
media: Ethernet autoselect
status: active
pair3: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> rdomain 1 mtu
1500
lladdr fe:e1:ba:d3:f4:76
priority: 0
patch: pair2
groups: pair
media: Ethernet autoselect
status: active
On Fri, Oct 30, 2015 at 11:34:39AM +0100, Reyk Floeter wrote:
> Hi,
>
> as documented below, pairs in bridges can lead to a loop.
>
> I looked at "fixing" it but came to the conclusion a) there is no
> satisfying way with mbuf flags/tags to prevent the loop, b) it would
> limit the use cases of pair(4) for network testing in many ways, c)
> the bridge loop causes heavy load but does not lock the system (our
> stack is already preventing this), and d) it can be documented -
> so it is a feature, and not a bug ;)
>
> Thoughts? OK?
>
> Reyk
>
> Index: share/man/man4/pair.4
> ===================================================================
> RCS file: /cvs/src/share/man/man4/pair.4,v
> retrieving revision 1.3
> diff -u -p -u -p -r1.3 pair.4
> --- share/man/man4/pair.4 24 Oct 2015 15:46:10 -0000 1.3
> +++ share/man/man4/pair.4 30 Oct 2015 10:09:34 -0000
> @@ -47,6 +47,25 @@ Set up a pair of interfaces where each o
> # ifconfig pair1 patch pair2
> # route -T 1 exec ping 10.1.1.2
> .Ed
> +.Pp
> +When adding multiple
> +.Nm
> +to multiple
> +.Xr bridge 4
> +interfaces, it is possible to create a loop;
> +the system load will go up while it is busy sending packets from one
> +bridge to another and back.
> +By design, the driver does not prevent such loops by itself, but it is
> +possible to use the Spanning Tree Protocol (STP) to detect and remove
> +loops in the virtual network topology:
> +.Bd -literal -offset indent
> +# ifconfig pair0 up
> +# ifconfig pair1 rdomain 1 patch pair0 up
> +# ifconfig pair2 up
> +# ifconfig pair3 rdomain 1 patch pair2 up
> +# ifconfig bridge0 add pair0 add pair2 stp pair0 stp pair2 up
> +# ifconfig bridge1 add pair1 add pair3 stp pair1 stp pair3 up
> +.Ed
> .Sh SEE ALSO
> .Xr bridge 4 ,
> .Xr inet 4 ,
>
--
