Bridges on VLAN-tagged interfaces.

Mon Mar 11 10:49:12 UTC 2019

Hi All.

I'm trying to create a bridge over a VLAN-tagged interface (to eventually use 
for a Xen VM, but we're a long way off that).

I've already tried to find a solution to this problem on the forum to no avail here:

https://forums.freebsd.org/threads/vlan-tagged-interfaces-in-bridges.69612/

The long and short of it is: I can get a vlan tagged interface to work, but I 
can't get a bridge that has a vlan tagged interface on it to work.

Clearly, I'm doing something wrong (being new to FreeBSD) but what?

Any help would be greatly apprecaited.

Here's more detail:

I'm trying to add a vlan tagged interface to a bridge.
I've got an interface called re0 on the server, this is part of bridge0 and 
bridge0 has an IP address that pings just fine.

I now create a vlan tagged interface thus:
ifconfig re0.33 create vlan 33 vlandev re0 up

If I put an IP address on that, it pings just fine.

OK, without that IP address, I now create bridge1:

Code:

|ifconfig bridge create ifconfig bridge1 addm re0.33|

If I now put an IP on that bridge instead of re0.33, it does not ping.

If I do a broadcast ping from another host on that network thus (Solaris system 
issuing the ping):
ping -sn 192.168.33.255

I can see packets arriving if I |tcpdump -i re0.33| and if I |tcpdump -i bridge1|
However, on neither interface do I see any pings coming in when I ping it's own 
address (in this case 192.168.33.20).
The Solaris system issuing the pings has learned the arp address of the bridge 
though:
Code:

|root at gaspra # arp -an | grep 192.168.33.20 net1 192.168.33.20 255.255.255.255 
02:a7:91:b6:3a:01|

If I |tcpdump -i bridge1|, I do get some packets, but not any echo requests:
Code:

|root at bianca # tcpdump -i bridge1 tcpdump: verbose output suppressed, use -v or 
-vv for full protocol decode listening on bridge1, link-type EN10MB (Ethernet), 
capture size 262144 bytes 11:05:26.081185 ARP, Request who-has 192.168.33.20 
(Broadcast) tell juliet-punchin.swangage.co.uk, length 46 11:05:26.081197 ARP, 
Reply 192.168.33.20 is-at 02:a7:91:b6:3a:01 (oui Unknown), length 28 
11:05:38.201079 IP6 fe80::7285:c2ff:fea6:583c > ff02::2: ICMP6, router 
solicitation, length 16 11:06:04.079441 ARP, Request who-has 192.168.33.20 
(Broadcast) tell juliet-punchin.swangage.co.uk, length 46 11:06:04.079464 ARP, 
Reply 192.168.33.20 is-at 02:a7:91:b6:3a:01 (oui Unknown), length 28 
11:06:17.588644 ARP, Request who-has 192.168.33.20 (Broadcast) tell 
gaspra-punchin.swangage.co.uk, length 46 11:06:17.588665 ARP, Reply 
192.168.33.20 is-at 02:a7:91:b6:3a:01 (oui Unknown), length 28|

So as you can see, the FreeBSD system does get ARP requests and does respond to 
them, but the pings never get there....

And here's the ifconfig output on the FreeBSD system being pinged:
Code:

|root at bianca # ifconfig -a re0: 
flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 
options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE> 
ether 80🇪🇪73:63:5c:48 media: Ethernet autoselect (1000baseT 
<full-duplex,master>) status: active nd6 
options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> lo0: 
flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 
options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6> inet6 ::1 
prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 
0xff000000 groups: lo nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> bridge0: 
flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether 
02:a7:91:b6:3a:00 inet 192.168.140.85 netmask 0xffffff00 broadcast 
192.168.140.255 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 
maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 root id 
00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: re0 
flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP> ifmaxaddr 0 port 1 priority 128 
path cost 55 groups: bridge nd6 options=9<PERFORMNUD,IFDISABLED> re0.33: 
flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 
options=80003<RXCSUM,TXCSUM,LINKSTATE> ether 80🇪🇪73:63:5c:48 inet6 
fe80::82ee:73ff:fe63:5c48%re0.33 prefixlen 64 scopeid 0x4 groups: vlan vlan: 33 
vlanpcp: 0 parent interface: re0 media: Ethernet autoselect (1000baseT 
<full-duplex,master>) status: active nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> 
bridge1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 
ether 02:a7:91:b6:3a:01 inet 192.168.33.20 netmask 0xffffff00 broadcast 
192.168.33.255 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 
maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 root id 
00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: re0.33 
flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP> ifmaxaddr 0 port 4 priority 128 
path cost 20000 groups: bridge nd6 options=9<PERFORMNUD,IFDISABLED> root at bianca #|

There are no firewalls involved at all here.

The system is currently not installed with Xen, just to remove something that 
might interfere for the time being.

I have also tried the software that comes with bhyve that creates the vlans and 
bridges: vm-bhyve and that didn't create working bridges either.

Someone suggested that the issue is that I'm also using the base interface re0, 
so I got rid of that and tried with just a vlan tagged interface in a bridge and 
that didn't help either.

I guess I'm arriving at: either I have a fundamental issue in my understanding 
of how to configure networking on FreeBSD, or I've come across some kind of bug?

Any pointers very gratefully received.

Thanks.

Eric

-- 

       ____
      /          .                           Eric A. Bautsch
     /--   __       ___                ______________________________________
    /     /    /   /                  /
   (_____/____(___(__________________/       email: eric.bautsch at pobox.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4127 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20190311/5ee53fa7/attachment-0001.bin>