Thank you Koshibe-san for your reply. Here is the output of ping, after the steps: $ ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes ping: sendmsg: Network is down ping: wrote 8.8.8.8 64 chars, ret=-1 ...
So, it seems the ping fails, except, this time there is some output. > > Interestingly, while searching for addlocal, I encountered a > > presentation on switch [1]. On page 13 of that pdf, there is mention of > > the switch sharing the STP code with bridge. Would it be correct to > > assume that there would be no loops if there was STP in the switch? > > Even with a bridge, you'd need to enable STP and set priority values > on the ports for it to work, so you're correct - if there were any > loops, the bridge probably wouldn't have worked either. But you've > also seen that, for switch(4), the STP-related options aren't > available in ifconfig, and as far as I can tell switchd doesn't do > topology/loop detection (and probably won't want to rely on (R)STP to > do so). So, the code might be shared, but is likely not used. I do not know much about the network stack, but I went grepping in the source, and I encountered a bstp_create function call in the switch_clone_create function within sys/net/if_switch.c file. This bstp_create function seems to be defined in sys/net/bridgestp.c [2]. I may be wrong here, but the bridge seems to have some kind of STP, since there is the "rstp" in the ifconfig output. Whether the switch does indeed use STP, and if it does, does it work, is something that I unfortunately cannot determine. For tap0, I ran "tcpdump -nettti tap0" on a normal machine, without the above vether. I saw a large stream of messages. Then I ran it on em0 interface. The "tcpdump -nettti em0" closely matched the output of tap0 interface output. This led me to try to understand tap interfaces. I encountered an article [3] and an image [4]. My hunch is that tap0 is sort of the mirror equivalent of em0. In terms of that image, em0 is the green physical NIC and tap0 is the Virtual Uplink Port. And since they are connected to two ends of the same (imaginary) cable, they will have the same set of messages. This leads me to believe that I should pass all traffic on tap0. Again, this is based on my uneducated guess and searching, so I could be wrong. Passing all traffic on tap0 still does not lead to the ping reply. However, doing a tcpdump on em0 shows an echo request and echo reply whiile tcpdump on tap0 only shows an echo reply. This is irrespective of addlocal vether0. Also, this is irrespective of the pf configuration. Now, why does the echo request not show up on tap0 and what is exactly stopping the echo reply to reach the ping command - I cannot determine. I have done the usual block log, tcpdump -netti pflog0 routine. There is infrequent igmp2 output, but nothing related to icmp. In fact, I have also used a one line "pass" file for pf configuration, still no ping reply. Regards, ab [1] - http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net/if_switch.c?rev=1.23&content-type=text/x-cvsweb-markup [2] - http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net/bridgestp.c?rev=1.65&content-type=text/x-cvsweb-markup [3] - www.innervoice.in/blogs/2013/12/08/tap-interfaces-linux-bridge/ [4] - https://i2.wp.com/www.innervoice.in/blogs/wp-content/uploads/2013/12/VirtualNetwotk.png ---------|---------|---------|---------|---------|---------|---------|--
