bridging VLAN interfaces and STP
Dustin J. Mitchell
dustin at v.igoro.us
Mon Aug 27 11:45:49 UTC 2012
On Mon, Aug 27, 2012 at 5:49 AM, Peter Jeremy <peter at rulingia.com> wrote:
> On 2012-Aug-26 08:12:51 -0400, "Dustin J. Mitchell" <dustin at v.igoro.us> wrote:
>>On Sat, Aug 25, 2012 at 7:04 PM, Dustin J. Mitchell <dustin at v.igoro.us> wrote:
>>> Hey folks. I'm trying to set up a system with one 802.1q-tagged
>>> upstream, and a few untagged interfaces. So I'd like to bridge the
>>> vlan(4) interfaces on vr1 to specific other interfaces.
>
> Can you provide ifconfig output covering all the relevant interfaces.
Sure:
vr0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric
0 mtu 1500
options=82809<RXCSUM,VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE>
ether 00:00:24:ce:ec:94
inet6 fe80::200:24ff:fece:ec94%vr0 prefixlen 64 scopeid 0x1
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect (none)
status: no carrier
vr1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric
0 mtu 1500
options=8280b<RXCSUM,TXCSUM,VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE>
ether 00:00:24:ce:ec:95
inet6 fe80::200:24ff:fece:ec95%vr1 prefixlen 64 scopeid 0x2
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
vr2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8280b<RXCSUM,TXCSUM,VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE>
ether 00:00:24:ce:ec:96
inet6 fe80::200:24ff:fece:ec96%vr2 prefixlen 64 scopeid 0x3
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect (none)
status: no carrier
vr3: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8280b<RXCSUM,TXCSUM,VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE>
ether 00:00:24:ce:ec:97
inet6 fe80::200:24ff:fece:ec97%vr3 prefixlen 64 scopeid 0x4
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect (none)
status: no carrier
vr1.10: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 00:00:24:ce:ec:95
inet 172.16.1.21 netmask 0xffffff00 broadcast 172.16.1.255
inet6 fe80::200:24ff:fece:ec95%vr1.10 prefixlen 64 scopeid 0x9
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
vlan: 10 parent interface: vr1
vr1.20: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST>
metric 0 mtu 1500
ether 00:00:24:ce:ec:95
inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
inet6 fe80::200:24ff:fece:ec95%vr1.20 prefixlen 64 scopeid 0xa
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
vlan: 20 parent interface: vr1
bridge10: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 02:f4:a1:63:5a:0a
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
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: vr3 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 4 priority 128 path cost 55
member: vr2 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 3 priority 128 path cost 55
member: vr1.10 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 9 priority 128 path cost 200000
bridge20: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 02:f4:a1:63:5a:14
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
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: vr0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 1 priority 128 path cost 55
member: vr1.20 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 10 priority 128 path cost 200000
>>And I can verify that STP's *not* working on those interfaces because
>>I just inadvertently created a forwarding loop.
>
> I'm not sure if this is intentional.
The forwarding loop certainly wasn't! It occurred when I had vr0
connected to a vlan 20 port, so bridge20 was involved.
>>Incidentally, it makes sense in retrospect, but the if_bridge(4)
>>manpage doesn't mention that gateway_enable is required for bridging
>>to actually forward packets.
>
> If this is true, it's definitely wrong and a regression.
> gateway_enable relates to routing not bridging.
My reason for thinking this was that the loop began immediately after
a reboot, having added
gateway_enable="YES"
firewall_enable="YES"
firewall_type="OPEN"
to rc.conf and
ipfw_load="YES"
ipdivert_load="YES"
net.inet.ip.fw.default_to_accept="1"
to loader.conf. So there could be other causes. It made so much
sense, I assumed it was the case!
Dustin
More information about the freebsd-net
mailing list